Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C Programming > Evaluation order of function parameters

Reply
Thread Tools

Evaluation order of function parameters

 
 
haroon
Guest
Posts: n/a
 
      11-23-2005
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

 
Reply With Quote
 
 
 
 
Antonio Contreras
Guest
Posts: n/a
 
      11-23-2005
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?

 
Reply With Quote
 
 
 
 
Richard Bos
Guest
Posts: n/a
 
      11-23-2005
"haroon" <(E-Mail Removed)> 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
 
Reply With Quote
 
aakash.joshi@matrixtelesol.com
Guest
Posts: n/a
 
      11-23-2005
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


 
Reply With Quote
 
pete
Guest
Posts: n/a
 
      11-23-2005
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
 
Reply With Quote
 
Ed Vogel
Guest
Posts: n/a
 
      11-23-2005

<(E-Mail Removed)> wrote in message
news:(E-Mail Removed) 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


 
Reply With Quote
 
Chris Dollin
Guest
Posts: n/a
 
      11-23-2005
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)
 
Reply With Quote
 
Randy Howard
Guest
Posts: n/a
 
      11-23-2005
haroon wrote
(in article
<(E-Mail Removed). 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





 
Reply With Quote
 
Christopher Benson-Manica
Guest
Posts: n/a
 
      11-23-2005
http://www.velocityreviews.com/forums/(E-Mail Removed) 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.
 
Reply With Quote
 
Kenny McCormack
Guest
Posts: n/a
 
      11-23-2005
In article <dm1v8c$6ao$(E-Mail Removed)>,
Christopher Benson-Manica <(E-Mail Removed)> 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.

 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Evaluation order of initializer list parameters Juha Nieminen C++ 2 11-19-2011 03:03 AM
Order of evaluation of function arguments dragoncoder C Programming 21 12-23-2005 07:08 PM
Order of function parameters evaluation subnet C Programming 13 03-09-2005 10:22 AM
Order of function evaluation Jens.Toerring@physik.fu-berlin.de C Programming 15 10-27-2003 07:45 PM
Evaluation order for nested function calls cheeser C++ 3 10-05-2003 08:10 AM



Advertisments