Path: utzoo!utgpu!utstat!jarvis.csri.toronto.edu!mailrus!ames!ncar!ico!haddock!karl
From: karl@haddock.ima.isc.com (Karl Heuer)
Newsgroups: comp.std.c
Subject: Semi-reserved namespace, revisited
Message-ID: <12209@haddock.ima.isc.com>
Date: 30 Mar 89 03:50:14 GMT
Sender: karl@ico.ISC.COM
Reply-To: karl@haddock.ima.isc.com (Karl Heuer)
Organization: Interactive Systems, Boston
Lines: 29

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.