Path: utzoo!mnetor!uunet!husc6!cmcl2!brl-adm!brl-smoke!gwyn
From: gwyn@brl-smoke.ARPA (Doug Gwyn )
Newsgroups: comp.lang.c
Subject: Re: parens honored
Message-ID: <7053@brl-smoke.ARPA>
Date: 12 Jan 88 00:59:24 GMT
References: <7022@brl-smoke.ARPA> <7564@elsie.UUCP>
Reply-To: gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>)
Organization: Ballistic Research Lab (BRL), APG, MD.
Lines: 37
Keywords: ANSI C standard

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

This is a good practice to follow, although difficult since many of the
essential things such as size_t simply don't exist in a portable way in
"old 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.)

And another goal is to remedy clear deficiencies.  If you had had to wade
through all the demands for something called "honoring parentheses", it would
be clear to you that many people perceived the "old C" license to rearrange
a couple of special cases as a clear deficiency.

A perhaps unannounced goal is to get the ANSI and ISO standards to track.
This unfortunately gives extra weight to ISO requests/demands that does
not apply to "ordinary" comments.  I don't think anything can really be
done about this other than to continue dialogues with ISO members.

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

But their problem will be mainly a forward-porting one.  It is extremely
unlikely that they will be able to import code written strictly for ANSI
C implementations.  For example, immediately their compilation will barf
when <stdlib.h> cannot be found, or when function prototypes are encountered.

Your situation is different -- because you plan in advance for the code to
fit both environments, you know not to count on parentheses being honored.
You'll therefore use temporary variables, etc. as required.  Such code can
be ported to other "old C" sites, with no problem related to parentheses.