Order of function parameters evaluation

S

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
 
A

Al Bowers

subnet said:
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
 
P

Peter Nilsson

subnet said:
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.
 
R

Richard Bos

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
 
S

subnet

Al Bowers said:
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 (<[email protected]>),
but please correct me if I'm wrong.

Thanks
 
O

Old Wolf

subnet said:
Al Bowers <[email protected]> wrote in message
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).
 
B

Ben Pfaff

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

Peter Nilsson

subnet said:
Al Bowers said:
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.
 
K

Keith Thompson

DHOLLINGSWORTH2 said:
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.
 
S

subnet

Ben Pfaff said:
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.
 
C

CBFalconer

*** rude top-posting fixed ***
DHOLLINGSWORTH2 said:
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.
 
D

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 said:
DHOLLINGSWORTH2 said:
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) (e-mail address removed)
<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.
 
C

CBFalconer

*** top-posting fixed ***
DHOLLINGSWORTH2 said:
Keith Thompson said:
.... 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/
 

Ask a Question

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

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,744
Messages
2,569,484
Members
44,903
Latest member
orderPeak8CBDGummies

Latest Threads

Top