ado@elsie.UUCP (Arthur David Olson) (06/01/88)
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@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.
gwyn@brl-smoke.ARPA (Doug Gwyn ) (06/03/88)
In article <8079@elsie.UUCP> ado@elsie.UUCP (Arthur David Olson) writes: > 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. 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. 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.
chris@mimsy.UUCP (06/03/88)
-In article <8079@elsie.UUCP> ado@elsie.UUCP (Arthur David Olson) writes: ->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. In article <8008@brl-smoke.ARPA> gwyn@brl-smoke.ARPA (Doug Gwyn ) writes: -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. Members of the committee should keep Mr. Murphy in mind. -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. This is probably the key to keeping implementors at bay. If the standard says that any program that avoids the described reserved identifiers (and does not violate other constraints) is `strictly conforming', this will suffice. Whether the standard in fact says this is uncertain to me. -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163) Domain: chris@mimsy.umd.edu Path: uunet!mimsy!chris
ado@elsie.UUCP (Arthur David Olson) (06/05/88)
> 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. Perhaps this is a matter of knowledge, simple-mindedness, and/or training. Doug, who has been active with the committee, may know from its deliberations that the committee's purpose in describing reserved identifiers was to say that all other identifiers are unreserved. I, a simple-minded Norwegian-American, assume that the committee's purpose in describing certain identifiers as reserved is to let me know that those identifiers are reserved. If the commiteee wants me (at least) to glean further information from the standard--for example, to conclude that it has provided a complete description of reserved identifiers--it needs to let me know that it has provided a complete description. The suggested addition-- Only external identifiers and macro names described in the Standard as reserved shall be reserved. --would be a way of doing this. As to training: my logic training was that if the Standard says that "Labradors are dogs," says that "Collies are dogs," and says nothing about poodles, it is unsafe for me to conclude that the Standard means to say that "Poodles are not dogs." Similarly, if the Standard says that "Identifiers in headers are reserved," says that "Identifiers beginning with 'is' are reserved, and says nothing about identifiers that begin with "xt", it is unsafe for me to conclude that the Standard means to say that "Identifiers that begin with 'xt' are not reserved." Doug seems more conversant with "fuzzy logic" than I am; are its teachings different in this matter? Are there changes I can make to my comment that will improve it with regard to this point? > 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. Well. . .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 Microsoft (purely for the sake of example) chooses to say that "os2" is a reserved external identifier, then any program that uses "os2" has undefined behavior (according to Section 4.1.2) and so cannot be "strictly conforming" (according to Section 1.7). Microsoft *does* accept any strictly conforming program-- since any program that uses "os2" isn't strictly conforming, at least by Microsoft's lights. Are there changes I can make to my comment that will improve it with regard to this point? -- ado@ncifcrf.gov ADO is a trademark of Ampex.