`Hiding' libc symbols

[Jacques A. Vidrine]

On Mon, May 05, 2003 at 11:14:17AM +0200, Harti Brandt wrote:
> On Thu, 1 May 2003, Jacques A. Vidrine wrote:
> 
> JAV>   (c) Hide all symbols, except those that are likely to
> JAV>       be candidates to be overridden.  malloc/free seem
> JAV>       to be the only ones here.
> 
> As far as I know, all programs from J.Schilling (cdrecord, star, ...)
> carry their own printf (and a good other half of libc). I suppose there
> are others that do this. While overriding libc functions is not exactly
> standard supported (as far as I understand), it has been used ever since.
> If there are un-overridable functions (for whatever reasons) they should
> be documented somewhere (say in the man page of that function). We should
> not expect application writers/porters to dig around in libc internals.

There are no un-overrideable functions.  I have never suggested making
any function un-overrideable.  Perhaps you are thinking of the standards
folk who claimed that qpopper had no business defining its own version
of `strlcpy'.

I did a survey of the currently-built binary packages for 5.x.  I
found that 714 packages define functions with the same name as those
defined in libc, and that there were 407 unique functions which were
hijacked in this way.

Over 25% of these functions are, happily, already hidden in libc.  The
remaining 296 different functions, ranging from `atoi' to `mkstemp' to
`vis', all may indicate subtle bugs.  (Realistically, the number of
truly buggy combinations is probably low.)

Some of these applications really want to override the functions for
their own purposes, like arts which overrides the hidden `open' stub.
Note that these applications work just fine even though the symbols are
`hidden' ... that is not the issue.

The rest of the applications seem to be defining their own versions of
some functions for portability purposes.  Defining `printf' seems pretty
funny, but J. Schilling is not the only author who has done so.
In these cases, it seems dangerous to have libc calling into the
application's implementation, e.g. calling Mozilla's `mkstemp' in order
to implement `hashopen', or calling Smiley's `bsearch' in order to
implement `nsdispatch', or calling MySQL's `strstr' to implement
`syslog' and so on and on.


So, I advocate hiding all symbols in libc by default.  The Real World
doesn't seem to care whether the symbols are defined by any standard or
not.

Or maybe someone wants to go fix the 714 `broken' ports and the
innumerable other applications that were not included in my survey.


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