Path: utzoo!utgpu!water!watmath!clyde!bellcore!faline!sabre!gamma!ulysses!allegra!mit-eddie!husc6!hao!ames!umd5!cvl!elsie!ado
From: ado@elsie.UUCP
Newsgroups: comp.lang.c
Subject: Re: parens honored
Message-ID: <7564@elsie.UUCP>
Date: 11 Jan 88 22:05:01 GMT
References: <7022@brl-smoke.ARPA>
Organization: NIH-LEC, Bethesda, MD
Lines: 34

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

At our lab we're doing our best to have code that will work in both
"old C" and "ANSI C" environments, so far without any insurmountable problems.
I think the assumption's safe.

> "Old C" is so amorphously ill-defined that there is no way we can guarantee
> anything about it.

Not so--we can guarantee that no "Old C" compiler honors parentheses,
which is why it's a bad idea to introduce the guarantee into ANSI C.
(Not honoring parentheses is the "clear and unambiguous" existing practice,
and one X3J11 goal, set forth in its Rationale document, is to follow such
practices where they exist.)

> 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.

There are far more exceptions than "unsupported compiler" users--
folks with very legitimate economic ("can't afford it"), political
("the compiler we're using has been stable for four years"), and technical
("the compiler vendors don't have a version for our obsolete,
two-year-old machine") reasons will be sticking (or stuck) with "old C"
for quite a while.

> (Explicit use of temporary variables has been
> declared "not acceptable" by many numerical programmers.)

Here's hoping that at the very least the arguments presented by these
numerical programmers show up in the Rationale document.
-- 
ado@vax2.nlm.nih.gov		ADO, VAX, and NIH are Ampex and DEC trademarks