Order of parameter evaulation

[Richard]

Boy, I'll sure bet this is a FAQ.

Many years ago, my "runtime behavior of programming languages" prof
absolutely guaranteed that C parameters are evaluated left-to-right.

He was a bright guy from CMU whose research focus was on programming
languages, and I believed him, but now I'm not so sure.

Little help?

 

[Alex]

Boy, I'll sure bet this is a FAQ.

Many years ago, my "runtime behavior of programming languages" prof
absolutely guaranteed that C parameters are evaluated left-to-right.

He was a bright guy from CMU whose research focus was on programming
languages, and I believed him, but now I'm not so sure.

Little help?

You're right, this is in the FAQ.

http://www.eskimo.com/~scs/C-faq/top.html

Or, more specifically:

http://www.eskimo.com/~scs/C-faq/q3.4.html

Alex

 

[Martin Ambuhl]

Boy, I'll sure bet this is a FAQ.

Many years ago, my "runtime behavior of programming languages" prof
absolutely guaranteed that C parameters are evaluated left-to-right.

He was a bright guy from CMU whose research focus was on programming
languages, and I believed him, but now I'm not so sure.

It's good not to be so sure: either he's wrong or your understanding of
what he said is wrong.

 

[pete]

Boy, I'll sure bet this is a FAQ.

Many years ago, my "runtime behavior of programming languages" prof
absolutely guaranteed that C parameters are evaluated left-to-right.

He was a bright guy from CMU whose research focus was on programming
languages, and I believed him, but now I'm not so sure.

Little help?

http://anubis.dkuug.dk/jtc1/sc22/wg14/www/docs/n869/

N869
3.19
[#1] unspecified behavior
behavior where this International Standard provides two or
more possibilities and imposes no requirements on which is
chosen in any instance

[#2] EXAMPLE An example of unspecified behavior is the
order in which the arguments to a function are evaluated.

 

[Richard]

(e-mail address removed) wrote...

You're right, this is in the FAQ.

http://www.eskimo.com/~scs/C-faq/top.html

Or, more specifically:

http://www.eskimo.com/~scs/C-faq/q3.4.html

Thanks--I saw that. I was thinking more like, for example,

if ( cond1 && (cond2 || cond3) ) {...}

is there a predictable order of parameter evaluation? My experience
is that this is undefined and compiler-specific.

I'm really sure about what he said, because we talked about it a few
times afterwards in the context of using the behavior in production
programs.

 

[Richard]

(e-mail address removed) wrote...

Boy, I'll sure bet this is a FAQ.

Many years ago, my "runtime behavior of programming languages" prof
absolutely guaranteed that C parameters are evaluated left-to-right.

He was a bright guy from CMU whose research focus was on programming
languages, and I believed him, but now I'm not so sure.

Little help?

http://anubis.dkuug.dk/jtc1/sc22/wg14/www/docs/n869/

N869
3.19
[#1] unspecified behavior
behavior where this International Standard provides two or
more possibilities and imposes no requirements on which is
chosen in any instance

[#2] EXAMPLE An example of unspecified behavior is the
order in which the arguments to a function are evaluated.

Perfect. Thank you very much. (My prof was right about everything
else!)

 

[Brett Frankenberger]

N869
3.19
[#1] unspecified behavior
behavior where this International Standard provides two or
more possibilities and imposes no requirements on which is
chosen in any instance

[#2] EXAMPLE An example of unspecified behavior is the
order in which the arguments to a function are evaluated.

Perfect. Thank you very much. (My prof was right about everything
else!)

But in another post, you ask about:
if (cond1 || cond2) {
[ ... ]
}
In that case, cond1 is guaranteed to be completely evaluated before
cond2. (And cond2 is guaranteed to be evaluated if and only if cond1
is zero.)

-- Brett

 

[Kevin Easton]

(e-mail address removed) wrote...

Thanks--I saw that. I was thinking more like, for example,

if ( cond1 && (cond2 || cond3) ) {...}

is there a predictable order of parameter evaluation? My experience
is that this is undefined and compiler-specific.

The && and || operators are something of a special case because they
(like the , and ?: operators) introduce additional sequence points. In
the expression:

a && (b || c)

Then a is completely evaluated first, and all side-effects happen. If a
was zero, then the result of the complete expression is zero and no
further evaluation happens. Otherwise, b is completely evaluated and
all side-effects take place - if b was non-zero, the result of the
complete expression is 1 and no further evaluation happens. Otherwise,
c is evaluated and the result of the complete expression is zero if c
was zero, otherwise it is 1. Any side-effects caused by evaluating c do
not necessarily take effect until the next sequence point.

On the other hand, in:

a & (b | c)

....then all of a, b and c are evaluated (unless the compiler can prove
that no visible side-effects result from some evaluation), in an
unspecified order. Any side-effects do not necessarily take effect
until the next sequence point.

- Kevin.

 

[pete]

N869
3.19
[#1] unspecified behavior
behavior where this International Standard provides two or
more possibilities and imposes no requirements on which is
chosen in any instance

[#2] EXAMPLE An example of unspecified behavior is the
order in which the arguments to a function are evaluated.

Perfect. Thank you very much. (My prof was right about everything
else!)

But in another post, you ask about:
if (cond1 || cond2) {
[ ... ]
}
In that case, cond1 is guaranteed to be completely evaluated before
cond2. (And cond2 is guaranteed to be evaluated if and only if cond1
is zero.)

.... which has nothing to do with parameters.
Parameters are the local objects in functions
which get initialized to the argument values in a function call

 

[Ben Pfaff]

Wrong. There is no such guarantee. In fact, I suspect that many
implementations always evaluate parameters from right to left.

Thanks--I saw that. I was thinking more like, for example,

if ( cond1 && (cond2 || cond3) ) {...}

is there a predictable order of parameter evaluation?

There aren't any parameters there, just operands. Functions have
parameters (the expression supplied as a parameter value is
called an argument), whereas operators have operands. && and ||
are special--they always evaluate their left operands first, and
then the right operand only if necessary. Most other operators
do not share this guarantee.

 

[Martin Ambuhl]

Richard wrote:

Thanks--I saw that. I was thinking more like, for example,

if ( cond1 && (cond2 || cond3) ) {...}

is there a predictable order of parameter evaluation? My experience
is that this is undefined and compiler-specific.

I was right: you misunderstood what was being said. There are *no*
parameters here, so parameter evaluation order is a red herring. So, you
see, it helps to ask the question in concrete terms (as here) rather than
in abstract terms (as before, when you used the wrong ones).
The order of evaluation of logical expressions is well-defined; in
particular, '&&' and '||' have left-to-right evaluation.

 

[Alex]

(e-mail address removed) wrote...

Thanks--I saw that. I was thinking more like, for example,

if ( cond1 && (cond2 || cond3) ) {...}

is there a predictable order of parameter evaluation? My experience
is that this is undefined and compiler-specific.

There are no parameters in your example.

Moreover, this is a special case due to C's short-circuit evaluation
in logical operators. If 'cond1' is false then there is no reason to
evaluate anything after the &&. If 'cond2' is true then there is no
reason to evaluate 'cond3'. Therefore, in this particular instance,
you are guaranteed left-to-right evaluation.

The evaluation order is somewhat dictated by 'sequence points'. The
end of a full expression is a sequence point, so are the '&&', '||',
'?', and ',' operators. In the absence of a sequence point, the
evaluation order is unspecified.

The following will be evaluated as written:

a();
b();
c();

This may not be:

int i = a() + b() + c();

Alex

 

[Keith Thompson]

You're right, this is in the FAQ.

http://www.eskimo.com/~scs/C-faq/top.html

Or, more specifically:

http://www.eskimo.com/~scs/C-faq/q3.4.html

Hmm. q3.4 talks about the order of evaluation of operands, but
doesn't directly refer to order of evaluation of function arguments.
In fact, I don't see anything in the FAQ that does.

I can imagine a hypothetical C-like language in which operands are
evaluated in an unspecified order, but function arguments are always
evaluated left-to-right. As far as I can tell, the C FAQ would be as
correct for this hypothetical language as it is for C.

Which is an annoyingly roundabout way of saying that the FAQ doesn't
seem to cover this point explicitly. (And it probably should.)

(But it turns out the OP wasn't talking about function arguments
anyway; if he'd asked the right question, he could have found the
answer in the FAQ.)

 

[Alex]

Hmm. q3.4 talks about the order of evaluation of operands, but
doesn't directly refer to order of evaluation of function arguments.
In fact, I don't see anything in the FAQ that does.

You're right, of course. I missed the word 'parameters' when I read
the original post. However, it seems that the OP did the same thing .

Alex