() ignored in some expressions

Larry Jones scjones at sdrc.UUCP
Tue Apr 10 07:49:32 AEST 1990

In article <48079 at lanl.gov>, u096000 at lanl.gov (Roger A. Cole) writes:
> In K&R1, expressions involving one of the associative and commutative
> operators can be arranged even when parenthesized.
> From the first time I read this, I've had difficulty not throwing up in
> instances where this applies.  I might be able to accept this *feature*
> a little more peacefully if someone could explain the basis for it.

Well, if the operators ARE commutative and associative, it
doesn't make any difference!  In the environment the C grew up
in, integer arithmetic overflows wrap around without producing
any exceptions, so the integer operators really are associative
and commutative.  Floating point, of course, is not so well
behaved, but very few C programs (historically speaking) use
floating point, and I would guess that most of them use it rather

Since C has so many operators with different precedences and a
preprocessor that encourages parenthesizing arguments, you end up
with a LOT of parentheses which are ensuring that the expression
is grouped correctly as opposed to specifying an evaluation
order.  Rearranging these expressions can generate much better
code, and, since floating point was not used seriously, it was
simpler to use the same rules for it.

> Is this feature also present in ANSI standard C?

No.  ANSI C requires that all expressions be evaluated as
written.  Thus for "a + b + c" the compiler must add a and b
first, then add c to the result.  However, the "as if" rule gives
implementors the latitude to rearrange to their heart's content
provided that the result is at least as good as the result of the
original expression.
Larry Jones                         UUCP: uunet!sdrc!scjones
SDRC                                      scjones at SDRC.UU.NET
2000 Eastman Dr.                    BIX:  ltl
Milford, OH  45150-2789             AT&T: (513) 576-2070
"You know how Einstein got bad grades as a kid?  Well MINE are even WORSE!"

More information about the Comp.lang.c mailing list