`Hiding' libc symbols

[Jacques A. Vidrine]

On Tue, May 06, 2003 at 11:43:13AM +0200, Harti Brandt wrote:
> To say it otherwise: I think hiding names that are not in Posix/Ansi is a
> good thing, because we must assume, that applications have functions with
> the same names doing entirely different things. Hiding names that are not
> standardized functions, but are in the standard or implementation
> namespace is probably a good thing to do too. Hiding functions that are in
> the standards is a bad thing. If applications use these names, we should
> assume that the function does at least what the standard requires. If not
> the application is broken and must be fixed. Otherwise we will break an
> unknown number of applications.

We _already_ hide many POSIX/ANSI names, without any ill effects or
portability consequences.  Please understand the issues before posting.

Since I set $SUBJECT, I will re-state what I meant by `hiding' libc
symbols.  I was specifically referring to the namespace.h/weak symbol
method which we have been using for over 100 functions in libc for
years.

That is:

Renaming the internal implementation of `foo' to `_foo', and creating
a weak symbol alias with the original name (`foo').  Within libc,
use the `_foo' name when the semantics must be known (e.g. when the
behavior must not be overridden by an application accidently, i.e.
almost always).  Macros in `namespace.h' help the compiler with
prototypes etc.

Cheers,
-- 
Jacques Vidrine   . NTT/Verio SME      . FreeBSD UNIX       . Heimdal
nectar at celabo.org . jvidrine at verio.net . nectar at freebsd.org . nectar at kth.se