Path: utzoo!mnetor!uunet!lll-winken!lll-lcc!ames!hao!gatech!mcnc!uvaarpa!umd5!cvl!elsie!ado
From: ado@elsie.UUCP (Arthur David Olson)
Newsgroups: comp.lang.c
Subject: Re: $1 check for first person who convinces me main can't be reserved
Message-ID: <8020@elsie.UUCP>
Date: 25 Feb 88 19:19:42 GMT
References: <8016@elsie.UUCP>
Organization: NIH-LEC, Bethesda, MD
Lines: 38

While the check has yet to be claimed, one correspondent has made me realize
that the Catch-22 applying to an "external reserved identifier" also applies
to a "keyword," as witness the following dialogue involving yours truly ("ME")
and an implementer ("IMP"):

	ME:	My program
			main() { return 0; }
		doesn't return zero.
	IMP:	Yeah. . .you misused a keyword.
	ME:	Huh?
	IMP:	Main.  One of our extensions makes it a keyword.
		You're not allowed to use it at all.
	ME:	What?  You can't make that extension!  It alters the
		behavior of my strictly conforming program!
	IMP:	Your program isn't strictly conforming.  You use a
		(extended) keyword, which Section 3.1.1 says you shall
		not do.  The "shall not" is not in a "Constraint" section.
		Section 1.6 says "If a 'shall' or 'shall not' requirement
		that appears outside of a constraint is violated, the
		behavior is undefined.'  And since your program produced
		"output dependent on. . .undefined. . .behavior," it isn't
		strictly conforming, per Section 1.7.

Providentially, this Catch-22 is even easier to deal with than the
"external reserved identifier" one (with the addition of one word only),
changing the sentence in Section 3.1.1 that begins

	The following tokens (entirely in lower-case) are reserved
	(in translation phases 7 and 8) for use as keywords. . .

to begin

	Only the following tokens (entirely in lower-case) are reserved
	(in translation phases 7 and 8) for use as keywords. . .

(You have to add a whole sentence to fix the external reserved identifier
problem.)
-- 
ado@vax2.nlm.nih.gov		ADO, VAX, and NIH are Ampex and DEC trademarks