Order of function parameters evaluation

Discussion in 'C Programming' started by subnet, Mar 7, 2005.

  1. subnet

    subnet Guest

    What does the standard say about this:

    #include <stdio.h>
    void somefunc(int a, int b, int c)
    {
    printf("%d %d %d\n", a, b, c);
    }

    int main(void) {
    int i = 5;
    somefunc(i++, i++, i++);
    return 0;
    }

    Compiling with gcc -Wall it gives:

    prog.c: In function `main':
    prog.c:10: warning: operation on `i' may be undefined
    prog.c:10: warning: operation on `i' may be undefined

    but it prints 7 6 5 anyway.

    Are the function arguments guaranteed to be evaluated right-to-left or
    this is not specified by the standard (and the above code produces
    UB)?

    Thanks
     
    subnet, Mar 7, 2005
    #1
    1. Advertising

  2. subnet

    Al Bowers Guest

    subnet wrote:
    > What does the standard say about this:
    >
    > #include <stdio.h>
    > void somefunc(int a, int b, int c)
    > {
    > printf("%d %d %d\n", a, b, c);
    > }
    >
    > int main(void) {
    > int i = 5;
    > somefunc(i++, i++, i++);
    > return 0;
    > }
    >
    > Compiling with gcc -Wall it gives:
    >
    > prog.c: In function `main':
    > prog.c:10: warning: operation on `i' may be undefined
    > prog.c:10: warning: operation on `i' may be undefined
    >
    > but it prints 7 6 5 anyway.
    >
    > Are the function arguments guaranteed to be evaluated right-to-left or
    > this is not specified by the standard (and the above code produces
    > UB)?
    >


    Reading the faq will be helpful.
    Its located at:
    http://www.eskimo.com/~scs/C-faq/top.html

    Start with question 3.2 at
    http://www.eskimo.com/~scs/C-faq/q3.2.html

    --
    Al Bowers
    Tampa, Fl USA
    mailto: (remove the x to send email)
    http://www.geocities.com/abowers822/
     
    Al Bowers, Mar 7, 2005
    #2
    1. Advertising

  3. subnet wrote:
    > What does the standard say about this:
    >
    > #include <stdio.h>
    > void somefunc(int a, int b, int c)
    > {
    > printf("%d %d %d\n", a, b, c);
    > }
    >
    > int main(void) {
    > int i = 5;
    > somefunc(i++, i++, i++);
    > return 0;
    > }


    It says the same thing as the last time someone asked this question.
    ;)

    The order of evaluation of function arguments is unspecified.
    Since the code modifies a variable more than once without a
    (guaranteed) intervening sequence point, the behaviour is
    undefined.

    > Compiling with gcc -Wall it gives:
    >
    > prog.c: In function `main':
    > prog.c:10: warning: operation on `i' may be undefined
    > prog.c:10: warning: operation on `i' may be undefined
    >
    > but it prints 7 6 5 anyway.


    Undefined behaviour lets an implementation do just about
    anything, including executing the code and producing output
    which seems valid.

    > Are the function arguments guaranteed to be evaluated right
    > -to-left or this is not specified by the standard (and the
    > above code produces UB)?


    It is specified as being 'unspecified'. This means that an
    implementation is free to choose any arbitrary ordering it
    likes, including middle-to-out (whatever that might mean,)
    or whatever-looks-easiest-to-compute-first.

    --
    Peter
     
    Peter Nilsson, Mar 7, 2005
    #3
  4. subnet

    Richard Bos Guest

    (subnet) wrote:

    > What does the standard say about this:
    > somefunc(i++, i++, i++);


    That it invokes undefined behaviour.

    > Compiling with gcc -Wall it gives:
    >
    > prog.c: In function `main':
    > prog.c:10: warning: operation on `i' may be undefined


    Which is correct.

    > but it prints 7 6 5 anyway.


    Undefined behaviour is allowed to do anything, including what you
    thought it should do, but also, more insidiously, doing so on your
    machine and crashing on your supervisor's (next-generation) computer.

    > Are the function arguments guaranteed to be evaluated right-to-left or
    > this is not specified by the standard (and the above code produces
    > UB)?


    The code produces undefined behaviour, but not (just) because the order
    of evaluation is unspecified. It _is_ unspecified, but if that were all
    you merely wouldn't know in what order it would print 5, 6 and 7.
    However, that's not all. You modify i three times without an intervening
    sequence point. This means that you invoke full-blown undefined
    behaviour, and the program is allowed to do literally anything within
    its powers, ranging from nothing to appearing to work to getting deeply
    confused and printing "Wibble!". Or worse. So don't do it.

    Richard
     
    Richard Bos, Mar 7, 2005
    #4
  5. subnet

    subnet Guest

    Al Bowers <> wrote in message news:<>...

    > Reading the faq will be helpful.
    >[snip]
    > Start with question 3.2 at
    > http://www.eskimo.com/~scs/C-faq/q3.2.html


    Yes, in fact I had already read the FAQ, and I'm aware of sequence
    points. The bit I was missing (and that the FAQ say nothing about) was
    that the the comma operator, *when used in a list of arguments for a
    function* does NOT introduce a sequence point, while it DOES introduce
    a sequence point when used in other circumstances (as written in FAQ
    3.8, which does not differentiate though).
    At least, this is my understanding after some google search on clc
    previous posts about the argument (<>),
    but please correct me if I'm wrong.

    Thanks
     
    subnet, Mar 7, 2005
    #5
  6. subnet

    Old Wolf Guest

    subnet wrote:
    > Al Bowers <> wrote in message

    news:<>...
    >
    > > Reading the faq will be helpful.
    > >[snip]
    > > Start with question 3.2 at
    > > http://www.eskimo.com/~scs/C-faq/q3.2.html

    >
    > Yes, in fact I had already read the FAQ, and I'm aware of sequence
    > points. The bit I was missing (and that the FAQ say nothing about)

    was
    > that the the comma operator, *when used in a list of arguments for a
    > function* does NOT introduce a sequence point, while it DOES

    introduce
    > a sequence point when used in other circumstances (as written in FAQ
    > 3.8, which does not differentiate though).


    If you read the language grammar, you will see that a comma
    used to separate function arguments is not actually an operator.

    "The comma operator" refers to the comma that separates
    expressions as part of a larger expression.

    An operator has one or more arguments, and a result. That
    cannot be said of the comma that separates function arguments.
    (Same goes for the comma that separates list items in a
    declaration).
     
    Old Wolf, Mar 7, 2005
    #6
  7. subnet

    Ben Pfaff Guest

    (subnet) writes:

    > Yes, in fact I had already read the FAQ, and I'm aware of sequence
    > points. The bit I was missing (and that the FAQ say nothing about) was
    > that the the comma operator, *when used in a list of arguments for a
    > function* does NOT introduce a sequence point, while it DOES introduce
    > a sequence point when used in other circumstances (as written in FAQ
    > 3.8, which does not differentiate though).


    A comma, used in the most common way in a function call, is not a
    comma operator:
    f(a, b, c); /* No comma operators. */

    You *can* use a comma operator in a function call, but
    parentheses or another kind of grouping is needed:
    g(a, (b, c), d[e, f]); /* Two uses of comma operator. */

    In the former case the commas are not sequence points. In the
    latter case, the two instances of a comma operator are sequence
    points.

    Make sense?
    --
    "...deficient support can be a virtue.
    It keeps the amateurs off."
    --Bjarne Stroustrup
     
    Ben Pfaff, Mar 7, 2005
    #7
  8. subnet wrote:
    > Al Bowers <> wrote...
    > > Reading the faq will be helpful.
    > >[snip]
    > > Start with question 3.2 at
    > > http://www.eskimo.com/~scs/C-faq/q3.2.html

    >
    > Yes, in fact I had already read the FAQ, and I'm aware of sequence
    > points. The bit I was missing (and that the FAQ say nothing about)
    > was that the the comma operator, *when used in a list of arguments
    > for a function* does NOT introduce a sequence point,


    That's because the comma token used to separate function arguments is
    _not_ a comma operator, but purely a syntactic delimiter.

    Consider ( and ). They have different interpretations depending on
    whether they are used in function declarators, primary expressions,
    or in postfix expressions (function calls.)

    It's all layed down in the C grammar.

    --
    Peter
     
    Peter Nilsson, Mar 7, 2005
    #8
  9. Try changing the calling convention to pascal.

    Then running it again.


    "subnet" <> wrote in message
    news:...
    > What does the standard say about this:
    >
    > #include <stdio.h>
    > void somefunc(int a, int b, int c)
    > {
    > printf("%d %d %d\n", a, b, c);
    > }
    >
    > int main(void) {
    > int i = 5;
    > somefunc(i++, i++, i++);
    > return 0;
    > }
    >
    > Compiling with gcc -Wall it gives:
    >
    > prog.c: In function `main':
    > prog.c:10: warning: operation on `i' may be undefined
    > prog.c:10: warning: operation on `i' may be undefined
    >
    > but it prints 7 6 5 anyway.
    >
    > Are the function arguments guaranteed to be evaluated right-to-left or
    > this is not specified by the standard (and the above code produces
    > UB)?
    >
    > Thanks
     
    DHOLLINGSWORTH2, Mar 8, 2005
    #9
  10. "DHOLLINGSWORTH2" <> writes:
    > "subnet" <> wrote in message
    > news:...
    >> What does the standard say about this:
    >>
    >> #include <stdio.h>
    >> void somefunc(int a, int b, int c)
    >> {
    >> printf("%d %d %d\n", a, b, c);
    >> }
    >>
    >> int main(void) {
    >> int i = 5;
    >> somefunc(i++, i++, i++);
    >> return 0;
    >> }
    >>
    >> Compiling with gcc -Wall it gives:
    >>
    >> prog.c: In function `main':
    >> prog.c:10: warning: operation on `i' may be undefined
    >> prog.c:10: warning: operation on `i' may be undefined
    >>
    >> but it prints 7 6 5 anyway.
    >>
    >> Are the function arguments guaranteed to be evaluated right-to-left or
    >> this is not specified by the standard (and the above code produces
    >> UB)?

    >
    > Try changing the calling convention to pascal.
    >
    > Then running it again.


    [top-posting corrected]

    The standard doesn't talk about a "calling convention" called
    "pascal", and any method for specifying such a thing is non-standard.

    Certainly a compiler can implement an extension that causes something
    that invokes undefined behavior to behave in a specified way. It can
    even define the behavior for some construct without implementing an
    extension (for example, its documentation might guarantee that
    function arguments are evaluated left-to-right -- encouraging users to
    write non-portable code).

    But the OP was specifically asking what the standard says.

    --
    Keith Thompson (The_Other_Keith) <http://www.ghoti.net/~kst>
    San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
    We must do something. This is something. Therefore, we must do this.
     
    Keith Thompson, Mar 8, 2005
    #10
  11. subnet

    subnet Guest

    Ben Pfaff <> wrote in message news:<>...

    > A comma, used in the most common way in a function call, is not a
    > comma operator:
    >[snip]
    > Make sense?


    Yes (bad wording on my side also).
    Thanks to everyone who replied.
     
    subnet, Mar 8, 2005
    #11
  12. subnet

    CBFalconer Guest

    *** rude top-posting fixed ***
    DHOLLINGSWORTH2 wrote:
    > "subnet" <> wrote in message
    >
    >> What does the standard say about this:
    >>

    .... snip ...
    >>
    >> int main(void) {
    >> int i = 5;
    >> somefunc(i++, i++, i++);
    >> return 0;
    >> }
    >>
    >> Compiling with gcc -Wall it gives:
    >>
    >> prog.c: In function `main':
    >> prog.c:10: warning: operation on `i' may be undefined
    >> prog.c:10: warning: operation on `i' may be undefined
    >>
    >> but it prints 7 6 5 anyway.
    >>
    >> Are the function arguments guaranteed to be evaluated right-to-left
    >> or this is not specified by the standard (and the above code
    >> produces UB)?

    >
    > Try changing the calling convention to pascal.
    >
    > Then running it again.


    There is no such thing in the C language. The behaviour is
    undefined.

    You have been asked several times to refrain from the rude
    top-posting.

    --
    "If you want to post a followup via groups.google.com, don't use
    the broken "Reply" link at the bottom of the article. Click on
    "show options" at the top of the article, then click on the
    "Reply" at the bottom of the article headers." - Keith Thompson
     
    CBFalconer, Mar 8, 2005
    #12
  13. Oh, I'm sorry I didn't mean to top post. I actually thought I would respond
    to someone who has no f'n idea why i'm responding OUT of SEQUENCE.

    From now on I will try to post out of sequence at your request.


    "Keith Thompson" <> wrote in message
    news:...
    > "DHOLLINGSWORTH2" <> writes:
    >> "subnet" <> wrote in message
    >> news:...
    >>> What does the standard say about this:
    >>>
    >>> #include <stdio.h>
    >>> void somefunc(int a, int b, int c)
    >>> {
    >>> printf("%d %d %d\n", a, b, c);
    >>> }
    >>>
    >>> int main(void) {
    >>> int i = 5;
    >>> somefunc(i++, i++, i++);
    >>> return 0;
    >>> }
    >>>
    >>> Compiling with gcc -Wall it gives:
    >>>
    >>> prog.c: In function `main':
    >>> prog.c:10: warning: operation on `i' may be undefined
    >>> prog.c:10: warning: operation on `i' may be undefined
    >>>
    >>> but it prints 7 6 5 anyway.
    >>>
    >>> Are the function arguments guaranteed to be evaluated right-to-left or
    >>> this is not specified by the standard (and the above code produces
    >>> UB)?

    >>
    >> Try changing the calling convention to pascal.
    >>
    >> Then running it again.

    >
    > [top-posting corrected]
    >
    > The standard doesn't talk about a "calling convention" called
    > "pascal", and any method for specifying such a thing is non-standard.
    >
    > Certainly a compiler can implement an extension that causes something
    > that invokes undefined behavior to behave in a specified way. It can
    > even define the behavior for some construct without implementing an
    > extension (for example, its documentation might guarantee that
    > function arguments are evaluated left-to-right -- encouraging users to
    > write non-portable code).
    >
    > But the OP was specifically asking what the standard says.
    >
    > --
    > Keith Thompson (The_Other_Keith)
    > <http://www.ghoti.net/~kst>
    > San Diego Supercomputer Center <*>
    > <http://users.sdsc.edu/~kst>
    > We must do something. This is something. Therefore, we must do this.
     
    DHOLLINGSWORTH2, Mar 9, 2005
    #13
  14. subnet

    CBFalconer Guest

    *** top-posting fixed ***
    DHOLLINGSWORTH2 wrote:
    > "Keith Thompson" <> wrote in message
    >>

    .... snip ...
    >>
    >> [top-posting corrected]
    >>

    .... snip ...
    >>
    >> But the OP was specifically asking what the standard says.

    >
    > Oh, I'm sorry I didn't mean to top post. I actually thought I
    > would respond to someone who has no f'n idea why i'm responding
    > OUT of SEQUENCE.
    >
    > From now on I will try to post out of sequence at your request.


    You make no sense, and I assume you do not understand, rather than
    being simply rude. In order to keep articles readable and
    understandable, most technical newsgroups require that you post
    your answer after, or intermixed with, the material to which you
    reply, and snip those portions that are not germane to your reply.

    Here are a few things to read:

    http://www.caliburn.nl/topposting.html
    http://www.netmeister.org/news/learn2quote.html
    http://www.catb.org/~esr/faqs/smart-questions.html
    http://www.greenend.org.uk/rjk/2000/06/14/quoting.html
    http://www.i-hate-computers.demon.co.uk/

    --
    Chuck F () ()
    Available for consulting/temporary embedded and systems.
    <http://cbfalconer.home.att.net> USE worldnet address!
     
    CBFalconer, Mar 9, 2005
    #14
    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:
    398
    Ilias Lazaridis
    Apr 24, 2005
  2. haroon

    Evaluation order of function parameters

    haroon, Nov 23, 2005, in forum: C Programming
    Replies:
    25
    Views:
    642
    Dave Thompson
    Dec 5, 2005
  3. Juha Nieminen
    Replies:
    2
    Views:
    252
    Johannes Schaub
    Nov 19, 2011
  4. Ilias Lazaridis
    Replies:
    74
    Views:
    780
    Ilias Lazaridis
    Apr 4, 2005
  5. Ilias Lazaridis
    Replies:
    18
    Views:
    355
    Bill Guindon
    Apr 9, 2005
Loading...

Share This Page