From owner-freebsd-arch@FreeBSD.ORG Mon May 5 11:44:01 2003 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3983B37B401; Mon, 5 May 2003 11:44:01 -0700 (PDT) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4857943F75; Mon, 5 May 2003 11:44:00 -0700 (PDT) (envelope-from eischen@pcnet1.pcnet.com) Received: from pcnet1.pcnet.com (localhost [127.0.0.1]) by mail.pcnet.com (8.12.8/8.12.1) with ESMTP id h45IhrBg026117; Mon, 5 May 2003 14:43:53 -0400 (EDT) Received: from localhost (eischen@localhost)h45Ihrkv026114; Mon, 5 May 2003 14:43:53 -0400 (EDT) Date: Mon, 5 May 2003 14:43:53 -0400 (EDT) From: Daniel Eischen To: "Jacques A. Vidrine" In-Reply-To: <20030505175426.GA19352@madman.celabo.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-arch@freebsd.org Subject: Re: Re: `Hiding' libc symbols X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 May 2003 18:44:01 -0000 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