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 Tue, 2 Nov 1999, Jimi X wrote:

> Date: Tue,  2 Nov 1999 11:26:47 -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:
> 
> [stuff snipped]
> 
> 
>  KK> On Mon, 1 Nov 1999, Steve Baker wrote:
>  >> Date: Mon, 1 Nov 1999 18:18:38 -0500 From: Steve Baker
>  >>
>  >> #include <stdio.h> include <sys/types.h> include <pwd.h>
>  >>
>  >> int uname;
> 
> This is a legal name, its not an ISO/ANSI name and therefore should
> always work.

Only if you are writing an ANSI C program. This means that you must
include only ANSI C headers, and use only ANSI C features. The ANSI C
parts of the library implementation therefore must not rely on being able
to use the external name uname for their own purposes, since it is
available to the ANSI C programmer. If, for some reason, use of the 
uname functionality can't be avoided in the ANSI C parts of the library,
then some alternative approach needs to be taken, like having a __uname
internal aliasing for uname.
 
>  KK> This invokes undefined behavior. The above identifier is a
>  KK> reserved external name in a POSIX application, such as this
>  KK> program, since it refers to the name of an existing function.
> 
> SYSV/POSIX reserves the _uname name implicitly (the "underbar rule).
> This is why we have write() and _write(). uname() is supposed to be a
> weak binding and therefore be overwritten.

My (albeit severely updated) POSIX spec doesn't mention anything about
weak symbols. Those are an implementation feature, as far as I know. 
A POSIX implementation could exist without support for weak symbols.
 
>  KK> It's more of a problem of the program's non-compliance rather
>  KK> than of namespace pollution.
> 
> Nope, It is name space pollution, clear and simple!
> The strong binding of uname() should be _uname or __uname uname MUST
> be weak (unless your on AIX which is a different matter all together).

It's because uname is in fact weak that the problem has happened. The
weakness of the uname symbol has allowed the external declaration

	int uname;

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

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

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


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