This is the mail archive of the glibc-linux@ricardo.ecn.wfu.edu mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: Namespace pollution?


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]