This is the mail archive of the
glibc-linux@ricardo.ecn.wfu.edu
mailing list for the glibc project.
Re: Namespace pollution?
- To: glibc-linux at ricardo dot ecn dot wfu dot edu
- Subject: Re: Namespace pollution?
- From: Kaz Kylheku <kaz at ashi dot footprints dot net>
- Date: Wed, 3 Nov 1999 15:59:31 -0800 (PST)
- Reply-To: glibc-linux at ricardo dot ecn dot wfu dot edu
On Wed, 3 Nov 1999, Martin v. Loewis wrote:
> Date: Wed, 3 Nov 1999 20:44:17 +0100
> From: Martin v. Loewis <martin@mira.isdn.cs.tu-berlin.de>
> Reply-To: glibc-linux@ricardo.ecn.wfu.edu
> To: glibc-linux@ricardo.ecn.wfu.edu
> Subject: Re: Namespace pollution?
>
> > MvL> I don't think '_uname' is reserved under that rule.
> > Nope its just saying that the implementation (or libc) own's that space.
>
> Maybe I'm nit-picking: Where exactly does it say that? It does start
> with an underscore, but that is followed *neither* by an upper-case
> letter, nor another underscore...
Don't know about POSIX or UNIX 98, but ANSI C reserves all identifiers
in the space that you describe (_[A-Z]* and __*) in all contexts even if no
header is included; they can be used for language extensions.
Identifiers that begin with an underscore and a lower case letter or digit are
merely reserved as file scope identifiers in the ordinary and tag namespace. At
least in C89. Thus ANSI C programs can use identifiers like _uname as long as
it's not at file scope or not in the ordinary or tag namespace---for example,
using them as names of structure members, names for block-scope declarations or
statement labels is fine. But a file scope declaration like ''struct _foo'' is
out, though programmers often abuse this rule when they follow the dubious
typedef _type { /*...*/ } type; style.
A library implementation can therefore use identifiers like _uname for the
names of external functions or objects, and provide declarations for these
entities in a header---even a standard C header! Or it can use them as
enum, struct or union tags, or for typedef names.
Some compilers (notably Microsoft's, somewhat unsurprisingly) violate the rules
by providing _[a-z]* macros for their platform-specific functions even when
operated in an ANSI C conforming mode. For example, their <stdio.h>
unconditionally #defines the macro '_fileno()'. What's worse, last I heard,
this practice is actually condoned by C9X. Thus what little ownership of that
namespace programmers have is taken away and given to library implementors.
I leave you coders with the following excellent URL:
http://www.mindspring.com/~brahms/c-predef.htm