Path: utzoo!utgpu!water!watmath!clyde!rutgers!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: <6986@brl-smoke.ARPA>
Date: 8 Jan 88 05:52:47 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>
Reply-To: gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>)
Organization: Ballistic Research Lab (BRL), APG, MD.
Lines: 16

In article <1798@bsu-cs.UUCP> dhesi@bsu-cs.UUCP (Rahul Dhesi) writes:
>Isn't it true though that in pre-ANSI K&R C, one could force a certain
>order of evaluation through the use of temporary variables, thus
>getting the best of both worlds?  ANSI C takes away this ability from
>the user.

How so?  I don't think this has changed one whit.

>It also will be a potential headache to the hardware designer ...

This shows that integer overflow trapping and optimization are at cross
purposes.  I certainly don't want both at the same time, because it
would make my patently correct code unreliable at run time.  People who
want integer overflow trapping should specify it in their RFPs, and if
that is a sizeable portion of the market, certainly vendors will provide
it.