Help wanted: second draft of comment to X3J11 on name space pollution
Arthur David Olson
ado at elsie.UUCP
Sun Jun 12 02:57:52 AEST 1988
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 at 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.
More information about the Comp.std.c
mailing list