Date: Tue, 6 May 2003 17:14:28 +0200 (CEST) From: Harti Brandt <brandt@fokus.fraunhofer.de> To: Terry Lambert <tlambert2@mindspring.com> Cc: freebsd-arch@freebsd.org Subject: Re: `Hiding' libc symbols Message-ID: <20030506165850.Y601@beagle.fokus.fraunhofer.de> In-Reply-To: <3EB7CC73.9C61C27E@mindspring.com> References: <20030501182820.GA53641@madman.celabo.org> <20030505110601.H53365@beagle.fokus.fraunhofer.de> <20030506093754.B838@beagle.fokus.fraunhofer.de> <3EB7CC73.9C61C27E@mindspring.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030506165850.Y601>