Order of function parameters evaluation

[subnet]

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

[Al Bowers]

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: xa******@myrapidsys.com (remove the x to send email)
http://www.geocities.com/abowers822/

[Peter Nilsson]

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

[Richard Bos]

su****@katamail.com (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

[subnet]

Al Bowers <xa******@rapidsys.com> wrote in message news:<39*************@individual.net>...

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 (<cl****************@plethora.net>),
but please correct me if I'm wrong.

Thanks

[Old Wolf]

subnet wrote:

Al Bowers <xa******@rapidsys.com> wrote in message news:<39*************@individual.net>...

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

[Peter Nilsson]

subnet wrote:

Al Bowers <xa******@rapidsys.com> 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

[Ben Pfaff]

su****@katamail.com (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

[DHOLLINGSWORTH2]

Try changing the calling convention to pascal.

Then running it again.
"subnet" <su****@katamail.com> wrote in message
news:9d**************************@posting.google.c om...

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

[Keith Thompson]

"DHOLLINGSWORTH2" <DH*************@cox.net> writes:

"subnet" <su****@katamail.com> wrote in message
news:9d**************************@posting.google.c om...

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) ks***@mib.org <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.

[subnet]

Ben Pfaff <bl*@cs.stanford.edu> wrote in message news:<87************@benpfaff.org>...

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.

[CBFalconer]

*** rude top-posting fixed ***
DHOLLINGSWORTH2 wrote:

"subnet" <su****@katamail.com> 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

[DHOLLINGSWORTH2]

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" <ks***@mib.org> wrote in message
news:ln************@nuthaus.mib.org...

"DHOLLINGSWORTH2" <DH*************@cox.net> writes:

"subnet" <su****@katamail.com> wrote in message
news:9d**************************@posting.google.c om...

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) ks***@mib.org
<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.

[CBFalconer]

*** top-posting fixed ***
DHOLLINGSWORTH2 wrote:

"Keith Thompson" <ks***@mib.org> 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 (cb********@yahoo.com) (cb********@worldnet.att.net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net> USE worldnet address!