[comp.std.c] Semi-reserved namespace, revisited

karl@haddock.ima.isc.com (Karl Heuer) (03/30/89)

The pANS says that the _[a-z0-9] namespace may be used by the implementation
for external identifiers.  (In contrast with the _[_A-Z] namespace, which
reserves all identifiers.)  I presume this means that the application is
permitted to use these names for non-external identifiers.  Thus, the
following program seems to be strictly conforming:
	#include <stdio.h>
	int main(void) {
	    char *_iob;
	    fprintf(stdout, "goodbye, world!\n");
	    return 0;
	}
If so, this implies that the common implementation of <stdio.h> is illegal (it
causes the above program to die horribly, because stdout is a macro that
references the name _iob).  Is this correct?

Does this also extend to application macros, since they have no linkage?  If
the program
	#define _ptr char *
	#include <stdio.h>
	int main(void) { return 0; }
is strictly conforming, it implies that <stdio.h> may not use _ptr as a struct
member; more generally, any undocumented identifier that actually appears in a
standard header, in *any* context%, must be from the _[_A-Z] namespace.

Are implementors prepared to make these modifications to the common headers?

Karl W. Z. Heuer (ima!haddock!karl or karl@haddock.isc.com), The Walking Lint
________
%The only exception I can think of is a formal argument in a macro definition.

gwyn@smoke.BRL.MIL (Doug Gwyn ) (03/31/89)

In article <12209@haddock.ima.isc.com> karl@haddock.ima.isc.com (Karl Heuer) writes:
>I presume this means that the application is permitted to use these names
>for non-external identifiers.

Well, you didn't cite the rules accurately.  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.  Thus, struct/
union tags starting with an underscore must never be used by a strictly
conforming program.

>the following program seems to be strictly conforming:
>	#include <stdio.h>
>	int main(void) {
>	    char *_iob;
>	    fprintf(stdout, "goodbye, world!\n");
>	    return 0;
>	}
>If so, this implies that the common implementation of <stdio.h> is illegal

Certainly the definition of `stdout' in <stdio.h> as
	#define	stdout	(&_iob[1])
	extern FILE	_iob[];
is not standard conforming, as you illustrate with your example.
Having `_iob' as an ordinary identifier in file scope is not a problem,
but the use of a non-reserved identifier in the definition of the
`stdout' macro is a problem.

>If the program
>	#define _ptr char *
>	#include <stdio.h>
>	int main(void) { return 0; }
>is strictly conforming, it implies that <stdio.h> may not use _ptr ...

But that's not strictly conforming, because ordinary identifiers in
file scope are reserved, and the program is in violation of that
constraint.

>Are implementors prepared to make these modifications to the common headers?

The implementors are obliged to conform to the standard, yessir.