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 Thu, 4 Nov 1999, Jimi X wrote:

> Date: Thu,  4 Nov 1999 10:17:49 -0500 (EST)
> From: Jimi X <jimix@pobox.com>
> Reply-To: glibc-linux@ricardo.ecn.wfu.edu
> To: glibc-linux@ricardo.ecn.wfu.edu
> Subject: Re: Namespace pollution?
> 
> >>>>> "KK" == Kaz Kylheku <kaz@ashi.footprints.net> writes:
> 
>  KK> 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...
> 
>  KK> Identifiers that begin with an underscore and a lower case letter
>  KK> or digit are merely reserved as file scope identifiers in the
>  KK> ordinary and tag namespace. At least in C89.
> 
> Posix agrees From the same page:
>     2. 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.  
> 
> More inbreeding :]

Inbreeding leading to redundancy. :) POSIX can't be any *less* restrictve than
the C standard that it inherits. It can't give the user the freedom to use
spaces that C already takes away.

> Wow, this is a real interesting discrepncy between the API atandards
> and the ABI spec.
> 
> Ultimately, POSIX and source code are API issues which were not
> violated by the source.  The ORIGINAL problem which happened at
> execution time (or more presicely link bind time with the runtime
> linker) is an ABI Issue (trying to execute global data as a function).

Yeah. The way I see it is that that program in question called a function which
invoked uname internally (what was it, getpwuid?).  That function and uname
sort of go together; I can't think of an interface that has getpwuid but not
uname except maybe BSD 4.3? That is to say, if you are using getpwuid, it's not
reasonable to expect to be able to use uname as your own external name.  The
getpwuid function is in POSIX, and was in SVID 3 as well as BSD 4.3. Don't all
of these have uname as well? Maybe BSD 4.3 didn't: so you might have a case if
you were targetting a program specifically for BSD 4.3, selected the
appropriate BSD 4.3 flags and got a crash.  

What we can say is that the library doesn't have a sufficiently fine-grained
mechanism to allow you to work in a purely BSD 4.3 environment in which there
is  no uname external symbol, so that you can use it for whatever you want.

There is also a good case for ensuring that the library does not call any of
its own external entry points. That is to say, for example, perhaps no function
should call uname(), but instead stick to calling some secret function like
__internal_uname. Thus you could use uname as your own external name, and only
redirect your own calls to it, not those in the system library.  If you wanted
to redirect the ``real'' uname, you would override __internal_uname.


> The SYSV ABI
> http://www.sco.com/developer/devspecs/gabi41.pdf
>   Page 6-3 System Service Synonyms
>   ...
>     name    This gives the traditional name, such as read.
>     _name   This gives a system service name that follows the ANSI C
>     convention of reserving symbols beginning with an underscore, such
>     as _read. 
> 
> a contradiction??

Not really; their statement of the ``ANSI C convention'' actually describes
rule that is weaker than the real ANSI C rule, which not reserves not only all
external names of the form _[0-9a-z]*, but also all such file-scope typedef
names, and struct/enum/union tags. Also, no header needs to be included
for the restriction to be in effect in any given translation unit.

External names are not explicitly mentioned in the rule, but that follows since
external names are introduced by external definitions, and external definitions
are necessarily at file scope in the ordinary namespace.


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