Path: utzoo!utgpu!water!watmath!clyde!rutgers!mit-eddie!uw-beaver!cornell!rochester!ur-tut!sunybcs!boulder!hao!ames!umd5!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: <7009@brl-smoke.ARPA>
Date: 9 Jan 88 09:29:49 GMT
References: <6829@brl-smoke.ARPA> <2845@zeus.TEK.COM> <6860@brl-smoke.ARPA> <12211@orchid.waterloo.edu> <6968@brl-smoke.ARPA> <1798@bsu-cs.UUCP> <6986@brl-smoke.ARPA> <1808@bsu-cs.UUCP>
Reply-To: gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>)
Organization: Ballistic Research Lab (BRL), APG, MD.
Lines: 13

In article <1808@bsu-cs.UUCP> dhesi@bsu-cs.UUCP (Rahul Dhesi) writes:
>ANSI C preserves only the second
>option--the user can no longer (on a machine that checks for overflow)
>use parens with wild abandon.  It is this ability to get "the best of
>both worlds" that ANSI C takes away.

I think you're looking at this the wrong way around.  The programmer
can still use parentheses any which way.  In fact, code that formerly
would mysteriously fail will now work the way it looks like it ought
to.  The only loss is a small amount of extra optimization under
quite limited circumstances (associating +s, or *s).  Some of this
can still be performed (folding integer constants under many common
circumstances).  Hardly an excessive price to pay for reliable code.