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?



Gang bang!

>>>>> "MvL" == Martin v Loewis <martin@mira.isdn.cs.tu-berlin.de> writes:
>>>>> "KK" == Kaz Kylheku <kaz@ashi.footprints.net> writes:

 MvL> Hmm. Looking at that page, I think I see what you refer to as
 MvL> "underbar rule":

 MvL> # 1. All identifiers that begin with an underscore and either an
 MvL> # upper-case letter or another underscore are always reserved
 MvL> # for any use by the implementation.

 MvL> I don't think '_uname' is reserved under that rule.
Nope its just saying that the implementation (or libc) own's that space.

 MvL> Also, when you say "we have ... _write()", who are you referring
 MvL> to, here? glibc uses __write/__libc_write (as _write is *not*
 MvL> reserved).
Sorry, that's in Solaris. but the two that you mention from glibc fall 
into the underbar rule.

 MvL> Please note that table 4. on this page reserves a number of
 MvL> additional identifiers, such as "symlink", for external linkage.

 MvL> I don't know why "uname" is not listed there; it is listed on

Thats just the document for the function though not a reserved name.

 KK> Only if you are writing an ANSI C program. This means that you
 KK> must include only ANSI C headers, and use only ANSI C
 KK> features. The ANSI C parts of the library implementation
 KK> therefore must not rely on being able to use the external name
 KK> uname for their own purposes, since it is available to the ANSI C
 KK> programmer. If, for some reason, use of the uname functionality
 KK> can't be avoided in the ANSI C parts of the library, then some
 KK> alternative approach needs to be taken, like having a __uname
 KK> internal aliasing for uname.

There is the rub, how do you maximize the support for as many specs as 
possible? There has been a lot of inbreeding between the specs and
historically SVID and POSIX were seperate, merged by XPGx into the
Single UNIX Specification (SUS) that we have now and call POSIX today.

uname() was originally part of SVID not POSIX (by the SVID) introduce
the "underbar rule".

 KK> My (albeit severely updated) POSIX spec doesn't mention anything
 KK> about weak symbols. Those are an implementation feature, as far
 KK> as I know.  A POSIX implementation could exist without support
 KK> for weak symbols.

I use weak as an example (sorry jumped ahead of myself on that one) of
the commonly know "hack" (and a hack it is) because we are all
consered with ELF and the SYSV ABI.

 KK> It's more of a problem of the program's non-compliance rather
 KK> than of namespace pollution.

I have a program that was written for XPG do I need to rewrite it to
set the necessary POSIX FLAGS?  The standards are a guarantee of
service and should strive not to cause restrictions.

Are you telling me that I cannot run, link and execute a fully ANSI C
program??

 KK> to override the library's uname function. Hence the program
 KK> crashed when it implicitly called uname through some intermediate
 KK> library function.

 KK> If uname weren't weak, the program would have failed to link,
 KK> which would have been preferrable, because the bug would have
 KK> been caught immediately.

AHH now this has nothing to do with standards but everything to do
with the link editor and the implementation fo providing the serveices
of the standards.  It is the internal libraries resposibility to make
sure the linker (runtime and editor) bind to the right thing.  If you
have ELF always use strong refernces within the library, if you have
XCOFF (AIX) then the the link editor describes binding order that the
runtime linker always obeys (WHEW).

Look in glibc, you will find internal code that calls write(),
__write() and __libc_write() (the later being the strong binding), and 
then a mess of #define macros that map write() to one of the other
ones. once you link in linux-threads they replace write() and
__write() with new functionality.

 KK> Weak symbols aren't a solution to pollution; they are merely a
 KK> hack to allow programmers to replace library functions with their
 KK> own, subject to the constraint that their replacements must objey
 KK> the interface and semantic constraints of the symbols they are
 KK> replacing.

Agree with "solution to polution" BUT they do not exist solely to
"replace library functions" (but its most handy there) but to allow
the programmer to control the interface name space.  I use the word
"interface" because this is not about function symbols alone but data
as well.

This is an argument that has been spinning around between people
smarter than all of us :].  Basically, we should all just strive NOT
to break ANY standard name space.

ANSI, C, ISO, POSIX, POSIX.1, POSIX.2, SUS, SUSv2, SVID, SVID3, XNS,
XNS4, XNS5, XPG, XPG3, XPG4, XPG4v2

Anything else missing?

-Jimi X

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