From owner-freebsd-arch@FreeBSD.ORG Tue May 6 08:14:36 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 F2D7637B401 for ; Tue, 6 May 2003 08:14:35 -0700 (PDT) Received: from mailhub.fokus.fraunhofer.de (mailhub.fokus.fraunhofer.de [193.174.154.14]) by mx1.FreeBSD.org (Postfix) with ESMTP id 87B8E43F3F for ; Tue, 6 May 2003 08:14:34 -0700 (PDT) (envelope-from brandt@fokus.fraunhofer.de) Received: from beagle (beagle [193.175.132.100])h46FESE20844; Tue, 6 May 2003 17:14:28 +0200 (MEST) Date: Tue, 6 May 2003 17:14:28 +0200 (CEST) From: Harti Brandt To: Terry Lambert In-Reply-To: <3EB7CC73.9C61C27E@mindspring.com> Message-ID: <20030506165850.Y601@beagle.fokus.fraunhofer.de> References: <20030501182820.GA53641@madman.celabo.org> <20030505110601.H53365@beagle.fokus.fraunhofer.de> <20030506093754.B838@beagle.fokus.fraunhofer.de> <3EB7CC73.9C61C27E@mindspring.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-arch@freebsd.org Subject: 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: Tue, 06 May 2003 15:14:36 -0000 On Tue, 6 May 2003, Terry Lambert wrote: TL>Peter Jeremy wrote: TL>> What if I define my own printf() that doesn't fully implement all the TL>> functionality of the FreeBSD printf()? It works meets all the requirements TL>> for my code (and maybe even runs correctly elsewhere) but doesn't work TL>> on FreeBSD because a library internal call (hypothetically) relies on TL>> functionality that I don't need. TL> TL>This is actually a library implementation problem, related to TL>incestuous implementation of library calls. TL> TL>If another library function doesn't use e.g. strlcpy() internally, TL>then it will not be effected by an application replacing strlcpy(). TL> TL>It's only when a library function depends on another library TL>function, rather than itself, that it's at risk for this type of TL>failure. It is also when two library functions dependend on implementation-internal data layout, initialisation sequence, whatever... TL>Perhaps instead of asking how to prevent symbol replacement, one TL>should be asking how to get rid of incestuous functions in the TL>library implementation for standard library functions. TL> TL>No, I do not expect "_fmt" (or whatever) to go away from common TL>code in printf/sprintf/whatever. But I do expect it to be "_fmt" TL>instead of "fmt", i.e. in implementation space, rather than in TL>the symbol space legal for users to use. That doesn't help in this case actually. the __foo() functions called by printf() depend on the internals of stdio, so internally calling _printf() while a user has replaced stdio will sure give you trouble. Another datapoint: glibc implements gcvt in terms of printf(). This is funny, because the intention of gcvt() is to implement printf(). By 'hiding' gcvt() through a weak symbol, there is no way an application can correct the buggy library. I have checked with the ISO-C draft I have around here. From a principal point of view, we are allowed to disable the redefinition of C-library functions. The question is, what does it help us and what do we loose: It helps us to catch one particular kind of bugs in 3rd party software, where the software has a buggy implementation (in the context of our own implementation) of a standard function. This also rules actually non-buggy implementations of functions that adhere to newer standards than our own implementations. This means that in order to actually help we have to go through each instance of a port redefining a libc function and decide, whether it is buggy, the same as our implementation or simply more featureful and whether it is compatible with our implementation. We loose the ability to do certain well known tricks (which have worked since C was invented), most of which help in debugging (f.e. replacing malloc or str* for range checking) and we make the porting of several software packages to FreeBSD actually harder. harti -- harti brandt, http://www.fokus.fraunhofer.de/research/cc/cats/employees/hartmut.brandt/private brandt@fokus.fraunhofer.de, harti@freebsd.org