ado@elsie.UUCP (Arthur David Olson) (05/29/87)
Page 64 of the draft C Standard's Rationale document reads (in part): . . .all external identifiers defined by the library are reserved [for the implementor]. . .Also reserved for the implementor are *all* external identifiers beginning with an underscore, and all other identifiers beginning with an underscore followed by a capital letter or an underscore. . .With these 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. Now I've been able to find the place in the Standard itself where "all external identifiers defined by the library are reserved." And I've been able to find the place where identifiers beginning with an underscore are reserved. But I've been unable to find the place in the Standard that assures that all other identifiers are available to the application programmer with no fear of unexpected collisions. I'd appreciate it if someone would quote the part of the Standard that provides the assurance. -- UUCP: ..seismo!elsie!ado ARPA: elsie!ado@seismo.CSS.GOV Elsie and Ado are trademarks of Borden, Inc. and Ampex.
gwyn@brl-smoke.ARPA (Doug Gwyn ) (05/30/87)
In article <7428@elsie.UUCP> ado@elsie.UUCP (Arthur David Olson) writes: >been unable to find the place in the Standard that assures that all other >identifiers are available to the application programmer with no fear of >unexpected collisions. I believe it was felt to be unnecessary (i.e. redundant), because a standard-conforming implementation is obliged to accept standard-conforming source and correctly implement the virtual machine semantics, which it couldn't do in some cases if it infringed on the programmer's name space. How about sending this in as a (late) public comment, to be sure that it gets addressed officially.
drw@cullvax.UUCP (Dale Worley) (06/03/87)
ado@elsie.UUCP (Arthur David Olson) writes: > But I've > been unable to find the place in the Standard that assures that all other > identifiers are available to the application programmer with no fear of > unexpected collisions. Probably this is stated "negatively", i.e., the general rules for using identifiers leads you to believe that "all other" identifiers work, and there is no special rule to tell you that the might not. Ergo, they work. (Many standards have an "escape clause" somewhere that says that the implementation can reserve any external identifiers it wants. (I think.)) Dale -- Dale Worley Cullinet Software UUCP: ...!seismo!harvard!mit-eddie!cullvax!drw ARPA: cullvax!drw@eddie.mit.edu Un*x (a generic name for a class of OS's) != Unix (AT&T's brand of such)