`Hiding' libc symbols

[Harti Brandt]

On Tue, 6 May 2003, Jacques A. Vidrine wrote:

JAV>On Tue, May 06, 2003 at 11:43:13AM +0200, Harti Brandt wrote:
JAV>> To say it otherwise: I think hiding names that are not in Posix/Ansi is a
JAV>> good thing, because we must assume, that applications have functions with
JAV>> the same names doing entirely different things. Hiding names that are not
JAV>> standardized functions, but are in the standard or implementation
JAV>> namespace is probably a good thing to do too. Hiding functions that are in
JAV>> the standards is a bad thing. If applications use these names, we should
JAV>> assume that the function does at least what the standard requires. If not
JAV>> the application is broken and must be fixed. Otherwise we will break an
JAV>> unknown number of applications.
JAV>
JAV>We _already_ hide many POSIX/ANSI names, without any ill effects or
JAV>portability consequences.  Please understand the issues before posting.
JAV>
JAV>Since I set $SUBJECT, I will re-state what I meant by `hiding' libc
JAV>symbols.  I was specifically referring to the namespace.h/weak symbol
JAV>method which we have been using for over 100 functions in libc for
JAV>years.

Please! I know what I'm talking about. I have been hit by the broken
shared library design in BSD/OS and I have been hit by all those
non-standard functions with names that each application writer loves to
use in our libc (err for example), but I have also on occasions replace
exit with abort to find a very obscure bug, I sometimes use a debugging
libmalloc, I know libraries that replace str* functions to find bound
errors.

I'm just telling that simply hiding all symbols without caring of what
that may cause is certainly wrong. And stating that this will
automagically make buggy ports un-buggier is also wrong.

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

Go ahead with non-standard functions, but make sure that you don't break
ports when doing this with standard functions.

harti
-- 
harti brandt,
http://www.fokus.fraunhofer.de/research/cc/cats/employees/hartmut.brandt/private
brandt at fokus.fraunhofer.de, harti at freebsd.org