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?


>>>>> "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 :]

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).

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??

  Page 5-19
    When resolving symbolic references, the dynamic linker examines
    the symbol tables with a breadth-first search.  That is, it first
    looks at the symbol table of the executable program itself, then
    at the symbol tables of the DT _ NEEDED entries (in order), then
    at the second level DT_NEEDED entries, and so on.  Shared object
    files must be readable by the process; other per-missions are not
    required.

It is glibc's internal code responsibility to go after the right
interface executable code linked with libraries cannot effect internal 
library linkage (unless the linker says otherwise ie. LD_PRELOAD).

What complicates this further in the example given is that private
inter-library calls exposed the matter.

More on uname:

Check out Page 6-11 Additional Entry Points (Processor-Specific) which
talkes about uname being processor specific. Then check out the i386 SYSV ABI:

http://www.sco.com/developer/devspecs/abi386-4.pdf

Page 6-2 Additional Entry Points

All I gotta say is that being all things to all specs is just a HUGE
pain in the @ss :]


-Jimi X

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