Path: utzoo!utgpu!water!watmath!clyde!rutgers!cmcl2!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: <7022@brl-smoke.ARPA>
Date: 11 Jan 88 07:27:37 GMT
References: <6829@brl-smoke.ARPA> <2845@zeus.TEK.COM> <6860@brl-smoke.ARPA> <7009@brl-smoke.ARPA> <7563@elsie.UUCP>
Reply-To: gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>)
Organization: Ballistic Research Lab (BRL), APG, MD.
Lines: 31

In article <7563@elsie.UUCP> ado@elsie.UUCP (Arthur David Olson) writes:
>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.

Assuming that ANSI C code had a chance of working in an "old C"
environment in the first place!

Actually, my real response to this is that such backward porting
hasn't been a concern of the committee, so far as I can tell, and
rightfully not.  "Old C" is so amorphously ill-defined that there
is no way we can guarantee anything about it.  That's what the
new standard version of the language will be for.  With the
exception of people running unsupported compilers, such as those
on 4.nBSD, most programmers will be porting in a forward direction
quite soon after the final standard is published.  Most C compiler
vendors I know of are either already tracking right behind the
ANSI C drafts, or they have made plans to do so not long after the
standard is published.  One reason for this is that it won't be
long before procurement contracts call for standard conformance.

I also think that many existing implementations pretty much
produce acceptable parentheses behavior (at least for integers),
even according to the new standard.  I refer to those with
"benign" integer overflow.  It is the floating-point world that
stands to gain the most from the new rule, and indeed some new
floating-point code may become non-robust if compiled with
compilers that rearrange evaluation order.  At least this is a
well-known problem, for which there is no acceptable alternative
in "old C".  (Explicit use of temporary variables has been
declared "not acceptable" by many numerical programmers.)