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?

--
Bush is blowing it.

[Alex]

Richard <rh***@hotmail. com> 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?

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]

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

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

[pete]

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

[Richard]

al*******@hotma il.com wrote...

Richard <rh***@hotmail. com> 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?

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.

--
Bush is blowing it.

[Richard]

pf*****@mindspr ing.com wrote...

Richard 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!)

--
Bush is blowing it.

[Brett Frankenberger]

In article <MP************ ************@ne ws.verizon.net> ,
Richard <rh***@hotmail. com> wrote:

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]

Richard <rh***@hotmail. com> wrote:

al*******@hotma il.com wrote...

Richard <rh***@hotmail. com> 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?

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.

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]

Brett Frankenberger wrote:

In article <MP************ ************@ne ws.verizon.net> ,
Richard <rh***@hotmail. com> wrote:

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

--
pete

[Ben Pfaff]

Richard <rh***@hotmail. com> writes:

Richard <rh***@hotmail. com> wrote:

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

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.
--
"It wouldn't be a new C standard if it didn't give a
new meaning to the word `static'."
--Peter Seebach on C99