Date: Mon, 5 May 2003 12:54:26 -0500 From: "Jacques A. Vidrine" <nectar@FreeBSD.org> To: Harti Brandt <brandt@fokus.fraunhofer.de> Cc: freebsd-arch@freebsd.org Subject: Re: Re: `Hiding' libc symbols Message-ID: <20030505175426.GA19352@madman.celabo.org> In-Reply-To: <20030505110601.H53365@beagle.fokus.fraunhofer.de> References: <20030501182820.GA53641@madman.celabo.org> <XFMail.20030501144502.jhb@FreeBSD.org> <20030501191027.GA53801@madman.celabo.org> <20030505110601.H53365@beagle.fokus.fraunhofer.de>
next in thread | previous in thread | raw e-mail | index | archive | help
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@celabo.org . jvidrine@verio.net . nectar@freebsd.org . nectar@kth.se
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030505175426.GA19352>