Date: Tue, 6 May 2003 11:17:33 -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: <20030506161732.GB78486@madman.celabo.org> In-Reply-To: <20030506175400.F631@beagle.fokus.fraunhofer.de> References: <20030501182820.GA53641@madman.celabo.org> <XFMail.20030501144502.jhb@FreeBSD.org> <20030505110601.H53365@beagle.fokus.fraunhofer.de> <20030505175426.GA19352@madman.celabo.org> <20030506093754.B838@beagle.fokus.fraunhofer.de> <20030506092519.GA3158@cirb503493.alcatel.com.au> <20030506112711.K838@beagle.fokus.fraunhofer.de> <20030506153641.GI77708@madman.celabo.org> <20030506175400.F631@beagle.fokus.fraunhofer.de>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, May 06, 2003 at 05:59:21PM +0200, Harti Brandt wrote: > Please! I know what I'm talking about. I have been hit by the broken > shared library design in BSD/OS and I have been hit by all those > non-standard functions with names that each application writer loves to > use in our libc (err for example), but I have also on occasions replace > exit with abort to find a very obscure bug, I sometimes use a debugging > libmalloc, I know libraries that replace str* functions to find bound > errors. You have yet to indicate how hiding some additional symbols in libc, using the method that we already have, will cause this hair loss to which you are referring. You can certainly replace `exit' with `abort' now if you want. As a matter of fact, `exit' is already `hidden' for a few years, and I haven't seen you complain earlier. % nm -D --defined-only /usr/lib/libc.so | grep '\b_\?exit\b' 0004368c W _exit 000a5558 T exit > I'm just telling that simply hiding all symbols without caring of what > that may cause is certainly wrong. I concede that might be the case. It seems clear that hiding the allocators might be of questionable use. Anything else? > And stating that this will > automagically make buggy ports un-buggier is also wrong. Well, we've already had at least one port where it most certainly made a difference. The issue is one of safety and robustness ... we should not be calling into application's functions _on accident_. > Go ahead with non-standard functions, but make sure that you don't break > ports when doing this with standard functions. Quick question: is strlcpy a standard function, or a non-standard function? What else are standard functions? Many `standard' functions are already hidden. I don't expect much, if any, breakage, but testing against the port cluster would be advisable before committing en masse. Actually, even if we had consensus to go this route, I'm not sure that one would want to do it en masse? 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?20030506161732.GB78486>