🚀 go-pugleaf

This is the second draft of a comment I plan to send to X3J11 on name space
pollution.  The first draft appeared in comp.lang.c.  I believe the comment
has already been strengthened as a result of responses to my first posting.
I'd again appreciate any suggestions on how to make the comment clearer,
more complete, and more compelling.  Thanks for your help!
-- 
	ado@ncifcrf.gov			ADO is a trademark of Ampex.

Standard, Section 97, Page 4.1.2, Line 22
Rationale, Section 7, Page 1.7
Rationale, Section 70, Page 4.1.2

Description

	On Page 7, the Rationale states that

		The external functions defined in, or called within, a
		portable program can be named whatever the programmer
		wishes, as long as these names are distinct from the
		external names defined by the Standard library
		(Section 4).

	On Page 70, the Rationale states that

		With [defined] exceptions, the Standard assures the
		programmer that all other identifiers are available,
		with no fear of unexpected collisions when moving
		programs from one implementation to another.

	But Section 4.1.2 and Section 4.1.13 of the Standard tell
	only what identifiers are reserved; they do not say that the
	described identifiers are the only identifiers that may be
	reserved.

	An unofficial response I've received indicates that the
	Committee feels the above constraint is already provided by
	the sentence in Section 4.1.2 which reads ``Each header
	declares and defines only those identifiers listed in its
	associated section.'' This sentence does indeed restrict the
	identifiers which may appear in headers, but there is no
	statement in the Standard that identifiers must appear in
	headers in order to be reserved.

	One person has stated that
		There wouldn't be much point in specifying what names
		are reserved unless the remaining names were
		unreserved.  I think the committee felt that that
		implication was clear enough.
	As an ``observer'' who's been unable to attend meetings, I
	assume that the Committee's purpose in describing certain
	identifiers as reserved is to let me know that those
	identifiers are reserved.  I would not (indeed, I believe I
	should not) draw further conclusions (for example, conclude
	that the Standard provides a complete description of
	reserved identifiers) in the absence of an explicit
	statement in the Standard.

	One person has stated that
		I also fail to see how an implementation could qualify
		as conforming if it usurped unreserved names.  It
		certainly could NOT "accept any strictly conforming
		program" as required in section 1.7.
	Now Section 4.1.2 says that ``If [a] program defines an
	external identifier with the same name as a reserved
	external identifier, even in a semantically equivalent form,
	the behavior is undefined.'' And Section 1.7 says that ``A
	strictly conforming program. . .shall not produce output
	dependent on any unspecified, undefined, or implementation-
	defined behavior.'' So if an implementor chooses to say that
	xyzzy is a reserved external identifier, then any program
	that uses xyzzy has undefined behavior (according to
	Section 4.1.2) and so cannot be ``strictly conforming''
	(according to Section 1.7).  The implementation does accept
	any strictly conforming program - since any program that
	uses xyzzy isn't strictly conforming, at least in the
	postulated implementation.

Proposed Change

	Either add the single-sentence paragraph

		Only external identifiers and macro names described in
		the Standard as reserved shall be reserved.

	to Section 4.1.2, or drop the statements quoted above about
	identifiers from the Rationale.