if bug in Ritchie C compiler

[utzoo!decvax!harpo!eagle!mhtsa!alice!npoiv!hou5f!wsh]

**************************************************************************

	I have just noticed a bug in the Ritchie C compiler (or at least
	an example of it being too smart for its own good)...

**************************************************************************

     We quote from the Gospel according to Kernighan and Ritchie (p. 185):
"Otherwise the order of evaluation of expressions is undefined.  In
particular the compiler considers itself free to compute subexpressions
in the order it believes most efficient, even if the subexpressions involve
side effects.  The order in which side effects take place is unspecified.
Expressions involving a commutatiave and associative operator (*, +, &,
|, ^) may be rearranged arbitrarily, even in the presence of parentheses;
to force a particular order of evaluation an explicit temporary must be
used."
     The lesson seems to be that the code cited in the original article
is not portable (assuming that the side effect from foo () is expected),
and that the Ritchie compiler is acting entirely correctly (if only
because the C language specification specifically relieves the compiler
of responsibility for any particular implementation).  Here is a case of
the code (rather than the compiler) being too smart for its own good
(again, assuming that the code expects foo () to be executed).  A
reasonable way to get around this problem is to use the comma operator;
the expression

     if (foo (), 0)

has the desired effect, in a well-defined way.

                                        Willie Heck
                                        abi - holmdel
                                        npoiv!hou5f!wsh