Order of Evaluation and Operator Precedence (WAS: Unsafe Optimizations)

In article <1990Jun14.032437.5554@esegue.segue.boston.ma.us>,
cwitty@csli.Stanford.Edu (Carl Witty) writes:


> > I would like to note that a number of languages are standardized such that
> > order of evaluation of certain items is *not specified*, ...
>
> I believe that this is not true for C. Instead, the rule is that
> the order of evaluation is exactly that specified by the precedence
> rules of the language, except in cases where it can be proven not to
> make a difference. (For example, on many machines, integer arithmetic
> really is commutative and associative.)


Careful; I think you're on thin ice here, at least in the way you phrased
your statement. Precedence rules of a language don't specify order of
evaluation at all. It is entirely possible for a language to be defined such
that "a + b * c + d" is syntactically equivalent to "a + (b * c) + d" --
i.e., multiplication has higher precedence than addition -- while specifying
nothing about the order in which a, b, c, and d are evaluated. Consider the
case in which a, b, c, and d are function invocations, where each function
outputs "This is function a" (resp. "b", "c", "d"), and returns 1, 2, 3, and
4, respectively. The precedence of multiplication over addition requires
that the final result be 11, not 36; but it says nothing about the order in
which messages appear on the output.


Indeed, C at least used to work exactly this way; the only guarantee was that
the expression would evaluate to 11, and that all four messages would be
printed in some order by the time execution reached the next "sequence point"
-- usually, the end of execution of the statement. Has this changed with
ANSI C?


jas
[ANSI says it must be computed as (a + (b * c)) + d, but the compiler is
free to evaluate the subexpressions in any order it wants, since there's no
sequence point in this expression. -John]
--

Return to the comp.compilers page.
Search the comp.compilers archives again.