Path: utzoo!utgpu!water!watmath!clyde!rutgers!ames!necntc!linus!philabs!pwa-b!mmintl!franka
From: franka@mmintl.UUCP (Frank Adams)
Newsgroups: comp.lang.c
Subject: Re: noalias; parens honored
Keywords: ANSI C standard
Message-ID: <2648@mmintl.UUCP>
Date: 12 Jan 88 21:41:55 GMT
References: <6829@brl-smoke.ARPA> <2845@zeus.TEK.COM> <6860@brl-smoke.ARPA> <12211@orchid.waterloo.edu>
Reply-To: franka@mmintl.UUCP (Frank Adams)
Organization: Multimate International, E. Hartford, CT.
Lines: 28

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.
>If the result of a macro is something like
>    ((a + 1) -1)
>then an honour parenthesis rule means the compiler
>can't optimize this to a simple "a" because it will have different
>overflow characteristics.

In this example, the rule does forbid full optimizing on many machines.
(One can still compute (a + 1), and then use a, skipping the subtraction.)

However, the more normal sort of case, such as ((a + 2) + 3) can still be
optimized on almost all architectures.  (There are doubtless exceptions, and
I really don't want to hear about them.)

I was one of those who did not like changing the language to force
parentheses to be honored, but I don't think it's such a bad thing --
certainly better than the monadic +.  I still like my idea of using square
brackets for parentheses which must be honored.  Now that the committee has
taken this step, maybe this idea can be revived for parentheses which do
*not* have to be honored.  Not for this version of the standard, of course,
but it seems like a reasonable extension for someone to try.
-- 

Frank Adams                           ihnp4!philabs!pwa-b!mmintl!franka
Ashton-Tate          52 Oakland Ave North         E. Hartford, CT 06108