Path: utzoo!yunexus!ists!jarvis.csri.toronto.edu!mailrus!shadooby!samsung!aplcen!haven!adm!smoke!gwyn
From: gwyn@smoke.BRL.MIL (Doug Gwyn)
Newsgroups: comp.std.c
Subject: Re: Macro names imbedded in pp-numbers [repost]
Message-ID: <11645@smoke.BRL.MIL>
Date: 19 Nov 89 01:10:52 GMT
Article-I.D.: smoke.11645
References: <11134@riks.csl.sony.co.jp> <15217@haddock.ima.isc.com> <1643@crdos1.crd.ge.COM> <1989Nov17.205004.19236@cs.rochester.edu> <1653@crdos1.crd.ge.COM>
Reply-To: gwyn@brl.arpa (Doug Gwyn)
Organization: Ballistic Research Lab (BRL), APG, MD.
Lines: 24

In article <1653@crdos1.crd.ge.COM> davidsen@crdos1.UUCP (bill davidsen) writes:
>I don't think this will bring a huge number of programs crashing down,

It won't.  Several committee members "grepped" for such usage in existing
code to see if it would be a significant factor.  For example, the whole
source code for UNIX was scanned.  We determined that it would not be a
significant problem for existing source code.

>but it does look like a case of a committee whose majority is
>vendors (or was during the two years I was there) choosing a behavior
>which has no benefit other than to simplify the writing of the parser.

That's a significant reason for this particular feature of the
specification.  However, you seem to be implying that selfish
considerations by vendors are acting to the detriment of users.
There were a significant number of user-oriented X3J11 committee
members (including myself), and of course most vendor representatives
also function as C users themselves.  We bought into the notion of
simplicitiy in this case as being of value to programmers as well as
implementors.  Only ignorant programmers might have a problem, but
that is true of very many aspects of C; C is not a language for those
who refuse to learn before doing.  We expect that this particular
quirk will be taught in C textbooks much as the need for () around
parameters in macro definitions already is taught.