«

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:
> 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?

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" <> wrote:

> 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?

<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:
> 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:
>
> 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?

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

--
pete

<> wrote in message
news: oups.com...
> 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 ???
>
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:

> Consider this function,
>
> void fun (int i, int j)
> {
> printf ("i = %d : j = %d", i, j);
> }
>
> I call it like this:
>
> fun (n++, n);

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.

> although the order of evaluation for function arguments is unspecified
> still shouldn't the compiler be consistent in its different versions?

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
<. com>):


> I call it like this:
>
> fun (n++, n);

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

wrote:

> atleast one shud expect similar kind of behavior from the different
> versions of the same compiler.

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?

> one can never argue .. as the C language doesnt specifies the behavior
> of such function calls. it is always compiler specific.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

"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$>,
Christopher Benson-Manica <> wrote:
....
>> one can never argue .. as the C language doesnt specifies the behavior
>> of such function calls. it is always compiler specific.
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>
>"Undefined" means undefined. A compiler/implementation need not
>behave in any documented or even reasonable way when faced with such
>situations.

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.