Path: utzoo!utgpu!water!watmath!clyde!rutgers!cmcl2!brl-adm!brl-smoke!gwyn
From: gwyn@brl-smoke.ARPA (Doug Gwyn )
Newsgroups: comp.lang.c
Subject: Re: parens honored
Keywords: ANSI C standard
Message-ID: <6968@brl-smoke.ARPA>
Date: 7 Jan 88 02:14:33 GMT
References: <6829@brl-smoke.ARPA> <2845@zeus.TEK.COM> <6860@brl-smoke.ARPA> <12211@orchid.waterloo.edu>
Reply-To: gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>)
Organization: Ballistic Research Lab (BRL), APG, MD.
Lines: 43

In article <12211@orchid.waterloo.edu> atbowler@orchid.waterloo.edu (Alan T. Bowler [SDG]) writes:
>If you have an situation where overflows are significant, then the
>"honour parenthesis" rule forbids the compiler from making even simple
>optimizations like constant folding.

True, but most (maybe all) implementations I have access to do not have
this problem.  I think SAS C on the IBM is the only one I know of (it
traps integer overflow), other than one's-complement architectures.
One of our system administrators once turned on floating-point overflow
trapping in our Gould PowerNode startup module, not realizing that the
hardware boundled it with integer overflow trapping and that the C code
generator was relying on benign integer overflow.  Lots of code crapped
out when it was relinked with the new startup module!

>    Note that this will apply to ALL floating point calculations,

Which is the main motivation behind the clamor for this specification.

>    With the new rule parentheses are being asked to perform 2 distinct
>actions
>    1) override the default precedence rules
>    2) specify the evaluation sequence.

Your analysis is essentially the one that the X3J11 committee used to
reject the constant demands for "honoring parentheses", until last
meeting where it was presented in a different light.

(2) was actually always implicit throughout the whole language, but
the base document (K&R Appendix A) contained a sentence that made an
explicit special dispensation for the order of mathematically
commutative and associative operators (+ and * being the main ones).
What X3J11 has done is remove the special license for optimizers to
rearrange such expressions in such a way that IT MAKES A POTENTIALLY
VISIBLE DIFFERENCE.  By the "as if" rule, an optimizer can still do
this if it can be sure that the effect is in all respects "as if" it
had strictly followed the evaluation order that the programmer
specified.

Hey, a lot of the committee didn't mind the way it was, but in the
end it was decided to help the programmer rather than the implementor.
I for one appreciate having my expressed algorithmic intentions
carried out precisely, instead of the compiler taking it upon itself
to "improve" things for me in ways that make my code unreliable.