Path: utzoo!mnetor!uunet!seismo!sundc!pitstop!sun!decwrl!decvax!mcnc!gatech!hao!ames!nrl-cmf!cmcl2!brl-adm!brl-smoke!gwyn
From: gwyn@brl-smoke.ARPA (Doug Gwyn )
Newsgroups: comp.lang.c
Subject: Re: $1 check for first person who convinces me main can't be reserved
Message-ID: <7365@brl-smoke.ARPA>
Date: 28 Feb 88 01:25:47 GMT
References: <8016@elsie.UUCP> <8020@elsie.UUCP> <7352@brl-smoke.ARPA> <8022@elsie.UUCP>
Reply-To: gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>)
Organization: Ballistic Research Lab (BRL), APG, MD.
Lines: 19

In article <8022@elsie.UUCP> ado@elsie.UUCP (Arthur David Olson) writes:
>	IMP:	Xyzzy.  One of our extensions makes it a keyword.
>		You're not allowed to use it at all.

I still don't think that a conforming implementation is anywhere given
license to introduce additional keywords.  However, I agree that in addition
to specifically mentioning constraints on identifier name space infringement
as is currently done in the draft proposed standard, it would be useful to
explicitly state such a constraint on keywords.  This would guarantee that
"pascal" (APW C keyword) and other such unexpected keywords would not
conflict with what the application programmer was using for his own purposes.
(It makes me uneasy to think that an ANSI C implementation would do this,
so I can support a clearly stated injunction against it in the standard.)
Note that we would presumably still want to allow conforming implementations
to define new keywords as extensions, but their names should be constrained
to start with an underscore, at the very least.  This is in fact probably
necessary in order to efficiently implement some library functions and
macros on some systems.  (It permits compiler "intrinsics", to use the
Fortran terminology.)