ado@elsie.UUCP (Arthur David Olson) (06/11/88)
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.