Help wanted on avoiding name space pollution

Arthur David Olson ado at elsie.UUCP
Thu Jun 2 02:54:28 AEST 1988


The ANSI C train is about to pull out of the station, meaning there's just one
opportunity left to try to help prevent name space pollution.  I've attached a
draft of a comment I plan to send to the Committee.  I'd appreciate any
suggestions for making the comment clearer and more likely to be accepted.
And if you're a C language user who's worried about name space pollution,
you might want to read the latest draft, draw your own conclusions, and send
in your own comments.
-- 
	ado at ncifcrf.gov			ADO is a trademark of Ampex.

===============================================================================

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

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 (\*S4).
	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.
Proposed Change
	Add the single-paragraph sentence
		Only external identifiers and macro names described in
		the Standard as reserved shall be reserved.
	to Section 4.1.2.

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



More information about the Comp.lang.c mailing list