mcdaniel@uicsrd.csrd.uiuc.edu (Tim McDaniel) (03/10/89)
In article <11982@haddock.ima.isc.com> karl@haddock.ima.isc.com (Karl Heuer) writes: >Karl W. Z. Heuer (ima!haddock!karl or karl@haddock.isc.com), The Walking Lint > _[a-z0-9][_A-Za-z0-9]* what I called semi-reserved I finally located a reference in K&R 2nd edition (p. 241): External identifiers that begin with an underscore are reserved for use by the library, as are all other identifiers that begin with an underscore and an upper-case letter or another underscore. (Of course, I couldn't find any references to this in the index, or in the "A2.3 Identifiers" section of the reference manual .... *sigh*) So, were K&R simplifying the issue, or did X3J11 change its mind after K&R2 was published, or what? (Note that I exclude the possibility of Karl being wrong. 8-) Assuming that there is "semi-reserved" namespace: what's the point of separating the namespaces to avoid namespace pollution, and then designating a polluted namespace? If I'm writing a pANS C program, I have to avoid semi-reserved names, because my implementation might be using them. If I'm writing a decent implementation for pANS C, I have to avoid using semi-reserved names, since a pANS C program might be using them, and I need to avoid gratuitous breakage. Therefore: semi-reserved names are, in practice, completely useless. -- Tim, the Bizarre and Oddly-Dressed Enchanter Center for ||| Internet, BITNET: mcdaniel@uicsrd.csrd.uiuc.edu Supercomputing ||| UUCP: {uunet,convex,pur-ee}!uiucuxc!uicsrd!mcdaniel Research and ||| ARPANET: mcdaniel%uicsrd@uxc.cso.uiuc.edu Development, ||| CSNET: mcdaniel%uicsrd@uiuc.csnet U of Illinois ||| DECnet: GARCON::"mcdaniel@uicsrd.csrd.uiuc.edu"
karish@forel.stanford.edu (Chuck Karish) (03/12/89)
In article <535@garcon.cso.uiuc.edu> mcdaniel@uicsrd.csrd.uiuc.edu (Tim McDaniel) wrote: >In article <11982@haddock.ima.isc.com> karl@haddock.ima.isc.com (Karl Heuer) writes: >> _[a-z0-9][_A-Za-z0-9]* what I called semi-reserved >I finally located a reference in K&R 2nd edition (p. 241): > External identifiers that begin with an underscore are reserved > for use by the library, as are all other identifiers that begin > with an underscore and an upper-case letter or another underscore. >So, were K&R simplifying the issue, or did X3J11 change its mind after >K&R2 was published, or what? (Note that I exclude the possibility of >Karl being wrong. 8-) Karl's right about the existence of a special class of names. These names are reserved for possible use by the implementation, according to Section 4.1.2 of the May, 1988 draft of the dpANS. If they are used in application programs, the behavior is undefined. They are, however, usable by programmers. If you're writing NON-PORTABLE library functions to support applications in a specific hardware/software environment, you can use this namespace (after checking for actual conflicts on your particular system) without polluting the namespace that is available for portable programs. Chuck Karish karish@denali.stanford.edu hplabs!hpda!mindcrf!karish (415) 493-7277
mcdaniel@uicsrd.csrd.uiuc.edu (Tim McDaniel) (03/13/89)
karl@haddock.ima.isc.com (Karl Heuer) writes (marked with ">"):
> _[a-z0-9][_A-Za-z0-9]* what I called semi-reserved
karish@forel.stanford.edu (Chuck Karish) writes (marked with "%"):
% These names are reserved for possible use by the implementation,
% according to Section 4.1.2 of the May, 1988 draft of the dpANS. If
% they are used in application programs, the behavior is undefined.
% They are, however, usable by programmers.
%
% If you're writing NON-PORTABLE library functions to support
% applications in a specific hardware/software environment, you can use
% this namespace (after checking for actual conflicts on your particular
% system) without polluting the namespace that is available for portable
% programs.
%
% Chuck Karish karish@denali.stanford.edu
% hplabs!hpda!mindcrf!karish
% (415) 493-7277
This behavior just seems so useless. It's not a problem for me,
understand; it's just something I'm scratching my head over and saying
"What were they thinking of?".
If I use the semi-reserved namespace, I have to "check for actual
conflicts on my particular system" (with the implementation and with
other libraries) and can avoid "polluting the namespace that is
available for portable programs." I have to check the implementation
uses because it might be using semi-reserved names.
If I use the reserved namespace, I HAVE TO DO THE EXACT SAME THINGS.
Either way, it's non-portable. Either way, the user namespace is not
polluted.
Am I missing something obvious? If so, PLEASE let me know and I'll
just shut up.
--
Tim, the Bizarre and Oddly-Dressed Enchanter
Center for ||| Internet, BITNET: mcdaniel@uicsrd.csrd.uiuc.edu
Supercomputing ||| UUCP: {uunet,convex,pur-ee}!uiucuxc!uicsrd!mcdaniel
Research and ||| ARPANET: mcdaniel%uicsrd@uxc.cso.uiuc.edu
Development, ||| CSNET: mcdaniel%uicsrd@uiuc.csnet
U of Illinois ||| DECnet: GARCON::"mcdaniel@uicsrd.csrd.uiuc.edu"bill@twwells.uucp (T. William Wells) (03/13/89)
In article <543@garcon.cso.uiuc.edu> mcdaniel@uicsrd.csrd.uiuc.edu (Tim McDaniel) writes:
: karl@haddock.ima.isc.com (Karl Heuer) writes (marked with ">"):
: > _[a-z0-9][_A-Za-z0-9]* what I called semi-reserved
:
: This behavior just seems so useless. It's not a problem for me,
: understand; it's just something I'm scratching my head over and saying
: "What were they thinking of?".
:
: If I use the semi-reserved namespace, I have to "check for actual
: conflicts on my particular system" (with the implementation and with
: other libraries) and can avoid "polluting the namespace that is
: available for portable programs." I have to check the implementation
: uses because it might be using semi-reserved names.
The difference between the two namespaces is this: the reserved space
can't portably be used in a hosted environment. The semi-reserved
space can, but not for externals. That, however, leaves #defines,
structure fields and tags, enumeration constants and tags, local
variables, and other items with internal or no linkage.
---
Bill
{ uunet | novavax } !twwells!bill
(BTW, I'm going to be looking for a new job sometime in the next
few months. If you know of a good one, do send me e-mail.)gwyn@smoke.BRL.MIL (Doug Gwyn ) (03/15/89)
In article <543@garcon.cso.uiuc.edu> mcdaniel@uicsrd.csrd.uiuc.edu (Tim McDaniel) writes: >karl@haddock.ima.isc.com (Karl Heuer) writes (marked with ">"): >> _[a-z0-9][_A-Za-z0-9]* what I called semi-reserved >Am I missing something obvious? If so, PLEASE let me know and I'll >just shut up. I don't understand why Karl wants to distinguish between "reserved" identifiers (which is a notion in the pANS) and "semi-reserved" identifiers (which is not). Certain identifiers have semantics specified by the pANS, and a large class of other identifiers (the "underscore" names) are reserved for possible use by implementations. There are several name spaces in C, and the exact class of reserved names is different for different name spaces (unfortunately, in my opinion), but a given identifier in a particular name space is either reserved or it is not. If an application uses a name that was reserved for implementations, it is no longer standard conforming; whether or not it gets away with it obviously depends on the implementation. (There are also some names that are reserved for future standards, but we don't seem to be talking about those.)
msb@sq.com (Mark Brader) (03/18/89)
Here's what section 4.1.2.1 actually says, in part: # All identifiers that begin with an underscore and either an # upper-case letter or another underscore are always reserved # for any use. # # All identifiers that begin with an underscore are always # reserved for use as identifiers with file scope in both the # ordinary identifier and tag name spaces. Karl elected to coin the term "semi-reserved" for the second group, there being no term defined in the proposed Standard. 4.1.2.1 goes on to describe the identifiers and identifier classes that are reserved by being specifically mentioned, as opposed to the syntactically distinguished ones mentioned above, and then says: # No other identifiers are reserved. If the program declares or # defines an identifier with the same name as an identifier reserved # in that context (other than as allowed by section 4.1.6 [that's # things like FILE *fopen(); in place of #include <stdio.h>]), the # behavior is undefined. A footnote notes that you have to be especially careful about macro names because they "are replaced wherever found, independent of scope and name space". All this seems clear enough to me. Mark Brader "I'm not a lawyer, but I'm pedantic and that's just as good." utzoo!sq!msb, msb@sq.com -- D Gary Grady