Evaluation order of function parameters

Discussion in 'C Programming' started by haroon, Nov 23, 2005.

  1. haroon

    haroon Guest

    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, Nov 23, 2005
    #1
    1. Advertising

  2. 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?
     
    Antonio Contreras, Nov 23, 2005
    #2
    1. Advertising

  3. haroon

    Richard Bos Guest

    "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
     
    Richard Bos, Nov 23, 2005
    #3
  4. haroon

    Guest

    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
     
    , Nov 23, 2005
    #4
  5. haroon

    pete Guest

    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
     
    pete, Nov 23, 2005
    #5
  6. haroon

    Ed Vogel Guest

    <> wrote in message
    news:...
    > 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
     
    Ed Vogel, Nov 23, 2005
    #6
  7. haroon

    Chris Dollin Guest

    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)
     
    Chris Dollin, Nov 23, 2005
    #7
  8. haroon

    Randy Howard Guest

    haroon wrote
    (in article
    <>):


    > 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
     
    Randy Howard, Nov 23, 2005
    #8
  9. 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.
     
    Christopher Benson-Manica, Nov 23, 2005
    #9
  10. 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.
     
    Kenny McCormack, Nov 23, 2005
    #10
  11. haroon a écrit :
    > Consider this function,
    >
    > void fun (int i, int j)
    > {
    > printf ("i = %d : j = %d", i, j);
    > }
    >
    > I call it like this:
    >
    > fun (n++, n);


    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
     
    Emmanuel Delahaye, Nov 23, 2005
    #11
  12. a écrit :
    > 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 ???


    No, it's not a C question. See

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

    --
    A+

    Emmanuel Delahaye
     
    Emmanuel Delahaye, Nov 23, 2005
    #12
  13. >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).

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

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

    Gordon L. Burditt
     
    Gordon Burditt, Nov 23, 2005
    #13
  14. In article <>,
    Gordon Burditt <> wrote:
    >>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).
    >
    >>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.
    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.

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


    True. But it *shouldn't* (see above) change unless there's a good reason
    for it to do so.
     
    Kenny McCormack, Nov 23, 2005
    #14
  15. Kenny McCormack wrote:
    > In article <>,
    > Gordon Burditt <> wrote:
    > >>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).
    > >
    > >>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.
    > 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.
    >
    > >>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.

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


    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
     
    David Resnick, Nov 23, 2005
    #15
  16. >>>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).
    >>
    >>>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.


    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".

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

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


    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
     
    Gordon Burditt, Nov 23, 2005
    #16
  17. In article <>,
    "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?


    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.
     
    Christian Bau, Nov 23, 2005
    #17
  18. In article <>,
    Gordon Burditt <> wrote:
    .... (someone else)
    >>>>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.

    >
    >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".


    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.

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

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

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


    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.
     
    Kenny McCormack, Nov 23, 2005
    #18
  19. In article <dm2u2p$rv5$>,
    Kenny McCormack <> wrote:

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


    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
     
    Richard Tobin, Nov 24, 2005
    #19
  20. haroon

    Richard Bos Guest

    (Kenny McCormack) wrote:

    > In article <>,
    > Gordon Burditt <> wrote:
    > ... (someone else)
    > >>>>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.

    > >
    > >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".

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


    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
     
    Richard Bos, Nov 24, 2005
    #20
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Ilias Lazaridis
    Replies:
    2
    Views:
    393
    Ilias Lazaridis
    Apr 24, 2005
  2. subnet

    Order of function parameters evaluation

    subnet, Mar 7, 2005, in forum: C Programming
    Replies:
    13
    Views:
    507
    CBFalconer
    Mar 9, 2005
  3. Juha Nieminen
    Replies:
    2
    Views:
    247
    Johannes Schaub
    Nov 19, 2011
  4. Ilias Lazaridis
    Replies:
    74
    Views:
    763
    Ilias Lazaridis
    Apr 4, 2005
  5. Ilias Lazaridis
    Replies:
    18
    Views:
    335
    Bill Guindon
    Apr 9, 2005
Loading...

Share This Page