Path: utzoo!utgpu!water!watmath!clyde!rutgers!gatech!hao!oddjob!mimsy!cvl!elsie!ado
From: ado@elsie.UUCP (Arthur David Olson)
Newsgroups: comp.lang.c
Subject: Re: parens honored
Summary: The real problem with honoring parens
Keywords: ANSI C standard
Message-ID: <7563@elsie.UUCP>
Date: 9 Jan 88 18:53:53 GMT
References: <6829@brl-smoke.ARPA> <2845@zeus.TEK.COM> <6860@brl-smoke.ARPA> <7009@brl-smoke.ARPA>
Organization: NIH-LEC, Bethesda, MD
Lines: 23

To me, the real problem with honoring parentheses is simple:  existing
implementations of C don't.  This means that when an ANSI C program that
"needs" such honoring gets ported back to an existing implementation,
things will break quietly and mysteriously.

However much folks have complained about it, X3J11's earlier technique of
using unary + to force parentheses to be honored was better with respect
to "backward portability":  code such as
	a = +(b + c) + d;
would be flagged by existing compilers as illegal, rather than being
accepted as legal but doing something different from what you intended.
(The same would be true of the
	a = [b + c] + d;
notion presented in this news group recently.)

And, of course, the founding parents got it right in the first place:
if order of evaluation is important, use a temporary variable; then there'll
be absolutely no way for a code reader to misinterpret the intent of the code.
Your modern, now, a-go-go compiler (the one that needs "noalias"
hints so it can produce spiffy code) will surely optimize the temporary
variable away.
-- 
ado@vax2.nlm.nih.gov		ADO, VAX, and NIH are Ampex and DEC trademarks