Date: Mon, 5 May 2003 14:43:53 -0400 (EDT) From: Daniel Eischen <eischen@pcnet1.pcnet.com> To: "Jacques A. Vidrine" <nectar@freebsd.org> Cc: freebsd-arch@freebsd.org Subject: Re: Re: `Hiding' libc symbols Message-ID: <Pine.GSO.4.10.10305051440510.25617-100000@pcnet1.pcnet.com> In-Reply-To: <20030505175426.GA19352@madman.celabo.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 5 May 2003, Jacques A. Vidrine wrote: > 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. I would tend to agree. For all the naysayers, perhaps have a look at NetBSD's namespace.h: http://cvsweb.netbsd.org/bsdweb.cgi/src/lib/libc/include/namespace.h?rev=1.76&content-type=text/x-cvsweb-markup -- Dan Eischen
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.GSO.4.10.10305051440510.25617-100000>