This is the mail archive of the
glibc-linux@ricardo.ecn.wfu.edu
mailing list for the glibc project.
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