Evaluation order of function parameters

Consider this function,

void fun (int i, int j)
{
printf ("i = %d : j = %d", i, j);
}

I call it like this:

fun (n++, n);

this when compiled with gcc 4.0 gives following out put:
i = 9 : j = 10

but on gcc 3.4.3 the out put is:
i = 9 : j = 9

although the order of evaluation for function arguments is unspecified
still shouldn't the compiler be consistent in its different versions?
can any one explain why did they change this in version 4 of gcc?

Rgrds,
haroon

haroon wrote:[color=blue]
> Consider this function,
>
> void fun (int i, int j)
> {
> printf ("i = %d : j = %d", i, j);
> }
>
> I call it like this:
>
> fun (n++, n);
>
> this when compiled with gcc 4.0 gives following out put:
> i = 9 : j = 10
>
> but on gcc 3.4.3 the out put is:
> i = 9 : j = 9
>
> although the order of evaluation for function arguments is unspecified
> still shouldn't the compiler be consistent in its different versions?
> can any one explain why did they change this in version 4 of gcc?[/color]

Your code invokes undefined behaviour, so the compiler is allowed to do
as it pleases. Why should it be consistent across versions, or even
across different compilations with the same version?

"haroon" <haroon.shafiq@gmail.com> wrote:
[color=blue]
> although the order of evaluation for function arguments is unspecified
> still shouldn't the compiler be consistent in its different versions?
> can any one explain why did they change this in version 4 of gcc?[/color]

<http://www.eskimo.com/~scs/C-faq/q3.2.html>.

HTH; HAND.

Richard

well haroon, i agree with you.
atleast one shud expect similar kind of behavior from the different
versions of the same compiler.

ya thats right ... tht, one shud never write such code in the first
place.
one can never argue .. as the C language doesnt specifies the behavior
of such function calls. it is always compiler specific.

bt i would like to know that wht might be the compiler designer
thinking while changing the behavior. i dnt think its an optimization
issue. any takers for this question ???

regards,
aakash

haroon wrote:[color=blue]
> Consider this function,
>
> void fun (int i, int j)
> {
> printf ("i = %d : j = %d", i, j);
> }
>
> I call it like this:
>
> fun (n++, n);
>
> this when compiled with gcc 4.0 gives following out put:
> i = 9 : j = 10
>
> but on gcc 3.4.3 the out put is:
> i = 9 : j = 9
>
> although the order of evaluation for function arguments is unspecified
> still shouldn't the compiler be consistent in its different versions?
> can any one explain why did they change this in version 4 of gcc?
>
> Rgrds,
> haroon[/color]

haroon wrote:[color=blue]
>
> Consider this function,
>
> void fun (int i, int j)
> {
> printf ("i = %d : j = %d", i, j);
> }
>
> I call it like this:
>
> fun (n++, n);
>
> this when compiled with gcc 4.0 gives following out put:
> i = 9 : j = 10
>
> but on gcc 3.4.3 the out put is:
> i = 9 : j = 9
>
> although the order of evaluation for function arguments is unspecified
> still shouldn't the compiler be consistent in its different versions?[/color]

No.
There's no reason why the code should do anything
that you think it should.

--
pete

<aakash.joshi@matrixtelesol.com> wrote in message
news:1132752234.804014.200470@z14g2000cwz.googlegr oups.com...[color=blue]
> bt i would like to know that wht might be the compiler designer
> thinking while changing the behavior. i dnt think its an optimization
> issue. any takers for this question ???
>[/color]
The compiler I work on will give different resutls on different
platforms. On a CISC platform, where there an instruction
to do a "fetch and increment", the program would
generate: 9 10. On a RISC platform, where there
is no such instruction, the output is 9 9.

It is possible that newer versions of gcc may notice
that the variable 'n' is never used after the call, and
does not generate code for the increment as that
code is not strictly needed. So, this could be an
optimization.

Ed Vogel
HP/Compaq/DEC C/C++ Engineering

haroon wrote:
[color=blue]
> Consider this function,
>
> void fun (int i, int j)
> {
> printf ("i = %d : j = %d", i, j);
> }
>
> I call it like this:
>
> fun (n++, n);[/color]

Undefined Behaviour. You modify the variable `n` /and/ access its
value for a purpose other than determinine the new value without
an intervening sequence point: that is explicitly UB.
[color=blue]
> although the order of evaluation for function arguments is unspecified
> still shouldn't the compiler be consistent in its different versions?[/color]

There is no such obligation.

--
Chris "another virtual machine" Dollin
"Certainly the absence of a smiley is not a syntax error or a constraint
violation, and therefore doesn't require a diagnostic." (Richard
Heathfield)

haroon wrote
(in article
<1132751033.161541.95470@g43g2000cwa.googlegroups. com>):

[color=blue]
> I call it like this:
>
> fun (n++, n);[/color]

See the clc faq. This has been asked 5,453 times over the last
decade.

--
Randy Howard (2reply remove FOOBAR)
"The power of accurate observation is called cynicism by those
who have not got it." - George Bernard Shaw

aakash.joshi@matrixtelesol.com wrote:
[color=blue]
> atleast one shud expect similar kind of behavior from the different
> versions of the same compiler.[/color]

Why would one expect any such thing? Even the same version of the
same compiler can easily and reasonably generate different code. My
Borland 5.4.1 compiler, for example, can be told to use 80486
instructions or Pentium Pro instructions. You want to place bets on
whether the behavior of code exhibiting undefined behavior will be the
same for these two instruction sets?
[color=blue]
> one can never argue .. as the C language doesnt specifies the behavior
> of such function calls. it is always compiler specific.[/color]
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

"Undefined" means undefined. A compiler/implementation need not
behave in any documented or even reasonable way when faced with such
situations.

--
Christopher Benson-Manica | I *should* know what I'm talking about - if I
ataru(at)cyberspace.org | don't, I need to know. Flames welcome.

In article <dm1v8c$6ao$1@chessie.cirr.com>,
Christopher Benson-Manica <ataru@nospam.cyberspace.org> wrote:
....[color=blue][color=green]
>> one can never argue .. as the C language doesnt specifies the behavior
>> of such function calls. it is always compiler specific.[/color]
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>
>"Undefined" means undefined. A compiler/implementation need not
>behave in any documented or even reasonable way when faced with such
>situations.[/color]

I don't see why you (and other so-called "regulars") bother to post these
bullshit answers. Well, actually, I do. You know perfectly well that to
the OP, they (your answers) are bullshit, but you do it to impress your
"peers" (other so-called "regulars").

It seems to me that a simple, short, crisp:

Not portable. Can't discuss it here. Blah, blah, blah.

is a lot more appropriate - much more likely to help the OP - than is your
long discourse on why it is not covered by the standard. For crying out
loud, the OP has already allowed as how it is non-standard; he doesn't need
to be told that (again & again). Again, a simple "Can't discuss it here"
is to the point, and may even bring a smile to the OP's face.

And that would be a good thing.

haroon a écrit :[color=blue]
> Consider this function,
>
> void fun (int i, int j)
> {
> printf ("i = %d : j = %d", i, j);
> }
>
> I call it like this:
>
> fun (n++, n);[/color]

Don't ever do that. Never. The behaviour is not portable. Unary
operators only make sense when used alone.

I you want this

fun (n + 1, n);
n++;

be explicit.

--
A+

Emmanuel Delahaye

aakash.joshi@matrixtelesol.com a écrit :[color=blue]
> bt i would like to know that wht might be the compiler designer
> thinking while changing the behavior. i dnt think its an optimization
> issue. any takers for this question ???[/color]

No, it's not a C question. See

news:comp.compilers
news:gnu.gcc.help

--
A+

Emmanuel Delahaye

>fun (n++, n);

You have invoked the wrath of undefined behavior - changing
and using the value of n without an intervening sequence point
(the comma in a function call is *NOT* a comma operator).
[color=blue]
>although the order of evaluation for function arguments is unspecified
>still shouldn't the compiler be consistent in its different versions?[/color]

No, it is not necessary for the output to be consistent in two
runs of the *SAME* program as compiled by the same compiler.
[color=blue]
>can any one explain why did they change this in version 4 of gcc?[/color]

The behavior might also change with different levels of optimization
on the same copy of the same compiler.

Gordon L. Burditt

In article <11o98qdjvd1rjc7@corp.supernews.com>,
Gordon Burditt <gordonb.9iqor@burditt.org> wrote:[color=blue][color=green]
>>fun (n++, n);[/color]
>
>You have invoked the wrath of undefined behavior - changing
>and using the value of n without an intervening sequence point
>(the comma in a function call is *NOT* a comma operator).
>[color=green]
>>although the order of evaluation for function arguments is unspecified
>>still shouldn't the compiler be consistent in its different versions?[/color]
>
>No, it is not necessary for the output to be consistent in two
>runs of the *SAME* program as compiled by the same compiler.[/color]

It is not necessary, 'tis true. But it should work right, anyway.
Note that there *is* a difference between should and necessary (where,
I think, we can interpret "necessary" as "required by law"). For example,
in real life, we should help each other, but we are not required by law to
do so.

Only lawyers and clc "regulars" think the two are synonymous.
[color=blue][color=green]
>>can any one explain why did they change this in version 4 of gcc?[/color]
>
>The behavior might also change with different levels of optimization
>on the same copy of the same compiler.[/color]

True. But it *shouldn't* (see above) change unless there's a good reason
for it to do so.

Kenny McCormack wrote:[color=blue]
> In article <11o98qdjvd1rjc7@corp.supernews.com>,
> Gordon Burditt <gordonb.9iqor@burditt.org> wrote:[color=green][color=darkred]
> >>fun (n++, n);[/color]
> >
> >You have invoked the wrath of undefined behavior - changing
> >and using the value of n without an intervening sequence point
> >(the comma in a function call is *NOT* a comma operator).
> >[color=darkred]
> >>although the order of evaluation for function arguments is unspecified
> >>still shouldn't the compiler be consistent in its different versions?[/color]
> >
> >No, it is not necessary for the output to be consistent in two
> >runs of the *SAME* program as compiled by the same compiler.[/color]
>
> It is not necessary, 'tis true. But it should work right, anyway.
> Note that there *is* a difference between should and necessary (where,
> I think, we can interpret "necessary" as "required by law"). For example,
> in real life, we should help each other, but we are not required by law to
> do so.
>
> Only lawyers and clc "regulars" think the two are synonymous.
>[color=green][color=darkred]
> >>can any one explain why did they change this in version 4 of gcc?[/color]
> >
> >The behavior might also change with different levels of optimization
> >on the same copy of the same compiler.[/color]
>
> True. But it *shouldn't* (see above) change unless there's a good reason
> for it to do so.[/color]

In addition to being a troll, I think your posting patterns on clc make
you look a fool. When I voted for google groups to have killfiles, you

and chellapa were mostly what I had in mind (Tisdale being quiet for
a while).

Your argument, if thought through, suggests that a compiler writer/
maintainer should have to have a handy regression suite that tests
all possible instances of undefined/unspecified behavior and verifies
that no outcomes differ with any changes they make. If you
can't see the difficulty with that, well...

-David

>>>fun (n++, n);[color=blue][color=green]
>>
>>You have invoked the wrath of undefined behavior - changing
>>and using the value of n without an intervening sequence point
>>(the comma in a function call is *NOT* a comma operator).
>>[color=darkred]
>>>although the order of evaluation for function arguments is unspecified
>>>still shouldn't the compiler be consistent in its different versions?[/color]
>>
>>No, it is not necessary for the output to be consistent in two
>>runs of the *SAME* program as compiled by the same compiler.[/color]
>
>It is not necessary, 'tis true. But it should work right, anyway.[/color]

The point is that there is *NO* *DEFINITION* *OF* *WRONG* in this
situation. *ANYTHING* it does is correct. I'll settle for "right"
meaning "not injuring or killing anyone or damaging equipment".
[color=blue]
>Note that there *is* a difference between should and necessary (where,
>I think, we can interpret "necessary" as "required by law"). For example,
>in real life, we should help each other, but we are not required by law to
>do so.[/color]
[color=blue]
>Only lawyers and clc "regulars" think the two are synonymous.
>[color=green][color=darkred]
>>>can any one explain why did they change this in version 4 of gcc?[/color]
>>
>>The behavior might also change with different levels of optimization
>>on the same copy of the same compiler.[/color]
>
>True. But it *shouldn't* (see above) change unless there's a good reason
>for it to do so.[/color]

And the good reason may well be is that you wanted optimization, and
it was faster to do things in a different order.

Gordon L. Burditt

In article <1132751033.161541.95470@g43g2000cwa.googlegroups. com>,
"haroon" <haroon.shafiq@gmail.com> wrote:
[color=blue]
> Consider this function,
>
> void fun (int i, int j)
> {
> printf ("i = %d : j = %d", i, j);
> }
>
> I call it like this:
>
> fun (n++, n);
>
> this when compiled with gcc 4.0 gives following out put:
> i = 9 : j = 10
>
> but on gcc 3.4.3 the out put is:
> i = 9 : j = 9
>
> although the order of evaluation for function arguments is unspecified
> still shouldn't the compiler be consistent in its different versions?
> can any one explain why did they change this in version 4 of gcc?[/color]

It is undefined behavior. One could say that you got what you deserved,
but you didn't. If you put that kind of code into production code, it
goes wrong, customers lose money, your company loses money, and you get
fired, that is when you got what you deserved.

In article <11o9difocundu5a@corp.supernews.com>,
Gordon Burditt <gordonb.5ety4@burditt.org> wrote:
.... (someone else)[color=blue][color=green][color=darkred]
>>>>although the order of evaluation for function arguments is unspecified
>>>>still shouldn't the compiler be consistent in its different versions?
>>>
>>>No, it is not necessary for the output to be consistent in two
>>>runs of the *SAME* program as compiled by the same compiler.[/color]
>>
>>It is not necessary, 'tis true. But it should work right, anyway.[/color]
>
>The point is that there is *NO* *DEFINITION* *OF* *WRONG* in this
>situation. *ANYTHING* it does is correct. I'll settle for "right"
>meaning "not injuring or killing anyone or damaging equipment".[/color]

But you see, that's the funny thing. According to a lot of the "regulars",
anything, anything is allowed, including re-formatting the hard disk and
blowing up the house. Luckily, you're not as loony as they are.
[color=blue][color=green]
>>Note that there *is* a difference between should and necessary (where,
>>I think, we can interpret "necessary" as "required by law"). For example,
>>in real life, we should help each other, but we are not required by law to
>>do so.[/color]
>[color=green]
>>Only lawyers and clc "regulars" think the two are synonymous.
>>[color=darkred]
>>>>can any one explain why did they change this in version 4 of gcc?
>>>
>>>The behavior might also change with different levels of optimization
>>>on the same copy of the same compiler.[/color]
>>
>>True. But it *shouldn't* (see above) change unless there's a good reason
>>for it to do so.[/color]
>
>And the good reason may well be is that you wanted optimization, and
>it was faster to do things in a different order.[/color]

Agreed. My point is that under stable conditions, it should (see above and
previous posts for what I mean by "should") do the same thing. Of course,
it is not "required" to do so.

In article <dm2u2p$rv5$1@yin.interaccess.com>,
Kenny McCormack <gazelle@interaccess.com> wrote:
[color=blue]
>Agreed. My point is that under stable conditions, it should (see above and
>previous posts for what I mean by "should") do the same thing.[/color]

What do you mean by "stable"? Obviously the exact same copy of the
compiler is likely to produce the same code tomorrow as today. But
all kinds of minor changes might make it change.

For example, trivial changes to the surrounding code might change the
registers available, resulting in different optimisation choices.

Even compiling the same code with the same compiler on different
releases of the same operating system might cause a change. The
compiler might use qsort() to choose between optimisations, and
different versions of qsort might return different results (because
it's not guaranteed to be stable). This is not just a theoretical
possibility: it was observed when gcc was used as part of the SPEC
benchmarks.

-- Richard

gazelle@yin.interaccess.com (Kenny McCormack) wrote:
[color=blue]
> In article <11o9difocundu5a@corp.supernews.com>,
> Gordon Burditt <gordonb.5ety4@burditt.org> wrote:
> ... (someone else)[color=green][color=darkred]
> >>>>although the order of evaluation for function arguments is unspecified
> >>>>still shouldn't the compiler be consistent in its different versions?
> >>>
> >>>No, it is not necessary for the output to be consistent in two
> >>>runs of the *SAME* program as compiled by the same compiler.
> >>
> >>It is not necessary, 'tis true. But it should work right, anyway.[/color]
> >
> >The point is that there is *NO* *DEFINITION* *OF* *WRONG* in this
> >situation. *ANYTHING* it does is correct. I'll settle for "right"
> >meaning "not injuring or killing anyone or damaging equipment".[/color]
>
> But you see, that's the funny thing. According to a lot of the "regulars",
> anything, anything is allowed, including re-formatting the hard disk and
> blowing up the house. Luckily, you're not as loony as they are.[/color]

The loon is on the other bank. If a case of UB formats your hard disk,
that's the fault of your OS for not preventing a random program from
doing so, _not_ of the C implementation. Ditto for all other seemingly
ridiculous suggestions.
If you, e.g., write a seemingly random value over a function pointer,
and then jump to it, are you doing this because you made a mistake - or
are you writing low-level kernel code which actually needs this? The
compiler cannot possibly know. The OS, which runs your code, does know
whether or not you're allowed to do this.
It's the implementation's job to let you shoot yourself in the foot, if
you write code to do so. The OS' job is, amongst others, to prevent the
bullet from reaching flesh unless you have Write permission on your own
extremities.

Richard

On 24 Nov 2005 00:01:15 GMT, in comp.lang.c , richard@cogsci.ed.ac.uk
(Richard Tobin) wrote:
[color=blue]
>In article <dm2u2p$rv5$1@yin.interaccess.com>,
>Kenny McCormack <gazelle@interaccess.com> wrote:
>[color=green]
>>Agreed. My point is that under stable conditions, it should (see above and
>>previous posts for what I mean by "should") do the same thing.[/color]
>
>What do you mean by "stable"? Obviously the exact same copy of the
>compiler is likely to produce the same code tomorrow as today.[/color]

Even this isn't guaranteed. Consider hardware that has parallel
execution pipelines, and today, only one is available but tomorrow,
two are. You could easily get two different sets of results.
[color=blue]
>For example, trivial changes to the surrounding code might change the
>registers available,[/color]

Or, more likely, other applications running on the same machine..

--
Mark McIntyre
CLC FAQ <http://www.eskimo.com/~scs/C-faq/top.html>
CLC readme: <http://www.ungerhu.com/jxh/clc.welcome.txt>

----== Posted via Newsfeeds.Com - Unlimited-Unrestricted-Secure Usenet News==----
http://www.newsfeeds.com The #1 Newsgroup Service in the World! 120,000+ Newsgroups
----= East and West-Coast Server Farms - Total Privacy via Encryption =----

On Thu, 24 Nov 2005 08:55:04 GMT, in comp.lang.c ,
rlb@hoekstra-uitgeverij.nl (Richard Bos) wrote:
[color=blue]
>The OS' job is, amongst others, to prevent the
>bullet from reaching flesh unless you have Write permission on your own
>extremities.[/color]

A new film title: "The umask of Zorro"

gd&r

--
Mark McIntyre
CLC FAQ <http://www.eskimo.com/~scs/C-faq/top.html>
CLC readme: <http://www.ungerhu.com/jxh/clc.welcome.txt>

----== Posted via Newsfeeds.Com - Unlimited-Unrestricted-Secure Usenet News==----
http://www.newsfeeds.com The #1 Newsgroup Service in the World! 120,000+ Newsgroups
----= East and West-Coast Server Farms - Total Privacy via Encryption =----

Kenny McCormack wrote:[color=blue]
> In article <dm1v8c$6ao$1@chessie.cirr.com>,
> Christopher Benson-Manica <ataru@nospam.cyberspace.org> wrote:[/color]
[color=blue][color=green][color=darkred]
> >> one can never argue .. as the C language doesnt specifies the behavior
> >> of such function calls. it is always compiler specific.[/color]
> > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> >
> >"Undefined" means undefined. A compiler/implementation need not
> >behave in any documented or even reasonable way when faced with such
> >situations.[/color]
>
> I don't see why you (and other so-called "regulars") bother to post these
> <expletive> answers.[/color]

it isn't nonesense. It's the absolute truth. I've seen quite radical
changes in behaviour
between different versions of the same compiler. I'm just curious about
why *you*
want to promulgate falsehoods.
[color=blue]
> Well, actually, I do. You know perfectly well that to
> the OP, they (your answers) are <expletive>, but you do it to impress your
> "peers" (other so-called "regulars").
>
> It seems to me that a simple, short, crisp:
>
> Not portable. Can't discuss it here. Blah, blah, blah.
>
> is a lot more appropriate - much more likely to help the OP - than is your
> long discourse on why it is not covered by the standard.[/color]

actually it *is* covered by the standard. The standard says the
behaviour is
undefined.
[color=blue]
> For crying out
> loud, the OP has already allowed as how it is non-standard; he doesn't need
> to be told that (again & again). Again, a simple "Can't discuss it here"
> is to the point, and may even bring a smile to the OP's face.
>
> And that would be a good thing.[/color]

it might be interesting as to why it is undefined.

--
Nick Keighley

"They consider console off topic, i consider them morons."
Anon (comp.lang.c)

"Nick Keighley" <nick_keighley_nospam@hotmail.com> wrote:
[color=blue]
> Kenny McCormack wrote:[color=green]
> > In article <dm1v8c$6ao$1@chessie.cirr.com>,
> > Christopher Benson-Manica <ataru@nospam.cyberspace.org> wrote:[/color]
>[color=green][color=darkred]
> > >"Undefined" means undefined. A compiler/implementation need not
> > >behave in any documented or even reasonable way when faced with such
> > >situations.[/color]
> >
> > I don't see why you (and other so-called "regulars") bother to post these
> > <expletive> answers.[/color]
>
> it isn't nonesense. It's the absolute truth. I've seen quite radical
> changes in behaviour between different versions of the same compiler.[/color]

Moreover, if you do not expect a significant change in behaviour between
different versions of an implementation, why bring out a new version at
all? Tempora mutantur, nos et mutamur in illis - for values of "nos"
that include compilers as well as programmers.

Richard

Kenny McCormack wrote:
[color=blue][color=green]
>>No, it is not necessary for the output to be consistent in two
>>runs of the *SAME* program as compiled by the same compiler.[/color]
>
>
> It is not necessary, 'tis true. But it should work right, anyway.[/color]

Why ? Invoking undefinied behaviour gives different results on multiple
platforms, on multiple versions of the same compiler, and with different
compilers. If you code undefined behaviour, expect things to break.

To all those who think it *should* : Please stay away from compilers and
code. People who do write conforming code already have to cope with bad
written shit like the OP posted.
[color=blue][color=green]
>>The behavior might also change with different levels of optimization
>>on the same copy of the same compiler.[/color]
>
>
> True. But it *shouldn't* (see above) change unless there's a good reason
> for it to do so.[/color]

Ah, and that is because it breakes behaviour that is undefined in the
first place ? *don't* write code like this, since it will break one way
or the other.

Igmar

On Wed, 23 Nov 2005 17:38:27 +0100, Emmanuel Delahaye
<emdel@YOURBRAnoos.fr> wrote:
[color=blue][color=green]
> > fun (n++, n);[/color]
>
> Don't ever do that. Never. The behaviour is not portable. Unary
> operators only make sense when used alone.
>[/color]
Nit: you mean mutating operators: assignment and increment/decrement.
Unary operators include +x -x &x *x !x ~x and sizeof x which can and
(always?) should be used with other operators.

- David.Thompson1 at worldnet.att.net

Evaluation order of function parameters

re: Evaluation order of function parameters

re: Evaluation order of function parameters

re: Evaluation order of function parameters

re: Evaluation order of function parameters

re: Evaluation order of function parameters

re: Evaluation order of function parameters

re: Evaluation order of function parameters

re: Evaluation order of function parameters

re: Evaluation order of function parameters

re: Evaluation order of function parameters

re: Evaluation order of function parameters

re: Evaluation order of function parameters

re: Evaluation order of function parameters

re: Evaluation order of function parameters

re: Evaluation order of function parameters

re: Evaluation order of function parameters

re: Evaluation order of function parameters

re: Evaluation order of function parameters

re: Evaluation order of function parameters

re: Evaluation order of function parameters

re: Evaluation order of function parameters

re: Evaluation order of function parameters

re: Evaluation order of function parameters

re: Evaluation order of function parameters

re: Evaluation order of function parameters

Similar C / C++ bytes

/bytes/development

/bytes/it

/bytes/about