Path: utzoo!mnetor!uunet!husc6!cmcl2!brl-adm!brl-smoke!gwyn
From: gwyn@brl-smoke.ARPA (Doug Gwyn )
Newsgroups: comp.lang.c
Subject: Re: X3J11 meeting notes
Message-ID: <6864@brl-smoke.ARPA>
Date: 18 Dec 87 22:16:53 GMT
References: <6829@brl-smoke.ARPA> <406@mn-at1.UUCP> <6852@brl-smoke.ARPA> <13899@think.UUCP>
Reply-To: gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>)
Organization: Ballistic Research Lab (BRL), APG, MD.
Lines: 47
Keywords: ANSI C standard

In article <13899@think.UUCP> barmar@sauron.think.com.UUCP (Barry Margolin) writes:
>and then rearrange the tree for optimization purposes.

That's what is NOT allowed for expressions, in the general case.
There is no need to add special flagging for parentheses.  If your
implementation takes advantage of a non-overflowing 2's complement
assumption, for example, then, yes, you may then need special
markers in the parse tree, although I'm not sure that you would if
you limit yourself to permitted optimizations.

>Of course, this type of parse tree node was already necessitated by
>unary plus.

Only if you were availing yourself of the license "the sentence"
granted you to rearrange certain expressions.  With that license
gone, in the general case there is no need for special stuff for
unary plus, either.  It is now really just a no-op (when legal).

>If overflow trapping exists, and equivalent behavior is required, very
>little optimization can be done.

Yes, that's right.  The committee came down on the side of the
programmer rather than the implementor, on this issue at least.

I think if you could rearrange so as to eliminate possible
overflow without introducing one where it couldn't have occurred
for the "virtual machine", then you're allowed to perform that
rearrangement, since you're into undefined-behavior territory,
where one of your options is to "do the right thing".

>The biggest problem I see with this requirement is due to macros.  In
>order to implement macros that expand into arithmetic operations and
>guarantee that they are well behaved it is necessary to use a level of
>parentheses, ...

Yes, that was one of the main counter-arguments the committee had
been using against dropping "the sentence".  However, on most
architectures the constant folding can still occur (and it WILL
occur in "constant expressions").  In the other cases, usually the
parentheses actually group a logical structure together, that is,
one that needs to have valid meaning in its own right, so
permitting overflow for it would not be justifiable.

Thanks for the comments, but in fact the committee was aware of
these things and chose to yield to "popular demand" to do something
about "parentheses".  Simply dropping "the sentence" was the best
solution.