Date: Tue, 6 May 2003 19:00:05 +0200 (CEST) From: Harti Brandt <brandt@fokus.fraunhofer.de> To: "Jacques A. Vidrine" <nectar@FreeBSD.org> Cc: freebsd-arch@FreeBSD.org Subject: Re: Re: `Hiding' libc symbols Message-ID: <20030506185026.B965@beagle.fokus.fraunhofer.de> In-Reply-To: <20030506161732.GB78486@madman.celabo.org> References: <20030501182820.GA53641@madman.celabo.org> <XFMail.20030501144502.jhb@FreeBSD.org> <20030505175426.GA19352@madman.celabo.org> <20030506092519.GA3158@cirb503493.alcatel.com.au> <20030506153641.GI77708@madman.celabo.org> <20030506161732.GB78486@madman.celabo.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 6 May 2003, Jacques A. Vidrine wrote: JAV>On Tue, May 06, 2003 at 05:59:21PM +0200, Harti Brandt wrote: JAV>> Please! I know what I'm talking about. I have been hit by the broken JAV>> shared library design in BSD/OS and I have been hit by all those JAV>> non-standard functions with names that each application writer loves to JAV>> use in our libc (err for example), but I have also on occasions replace JAV>> exit with abort to find a very obscure bug, I sometimes use a debugging JAV>> libmalloc, I know libraries that replace str* functions to find bound JAV>> errors. JAV> JAV>You have yet to indicate how hiding some additional symbols in libc, JAV>using the method that we already have, will cause this hair loss to JAV>which you are referring. You can certainly replace `exit' with `abort' JAV>now if you want. As a matter of fact, `exit' is already `hidden' for JAV>a few years, and I haven't seen you complain earlier. Well that may be some years ago actually, when I also decided to rename the err() function in my PDP-11 emulator :-( With exit() the situation actually seems a little bit more complex, because there is already an _exit() with different semantics. JAV>> I'm just telling that simply hiding all symbols without caring of what JAV>> that may cause is certainly wrong. JAV> JAV>I concede that might be the case. It seems clear that hiding the JAV>allocators might be of questionable use. Anything else? Watch out for Schilling's programs (star, cdrecord). And other programs that use to carry half of libc around. JAV>> And stating that this will JAV>> automagically make buggy ports un-buggier is also wrong. JAV> JAV>Well, we've already had at least one port where it most certainly JAV>made a difference. The issue is one of safety and robustness ... JAV>we should not be calling into application's functions _on accident_. Actually fixing the problem at the source would be even better. JAV>> Go ahead with non-standard functions, but make sure that you don't break JAV>> ports when doing this with standard functions. JAV> JAV>Quick question: is strlcpy a standard function, or a non-standard JAV>function? What else are standard functions? All str* functions are in the implementation name space so any program using a name starting with str is non-conforming. At the moment I cannot start my acroread or I would point you at the corresponding paragraph in ISO-C. Add posix to this. JAV>Many `standard' functions are already hidden. I don't expect much, if JAV>any, breakage, but testing against the port cluster would be advisable JAV>before committing en masse. Hmm. That means you ensure that the program compiles and links, not that it runs. A question that just occured to me is: how is one expected to find out via autoconf, whether to use a _ in front of the questionable function or not? It will compile and link without a warning in either case and provoking a run-time error may actually not be simple. JAV>Actually, even if we had consensus to go this route, I'm not sure that JAV>one would want to do it en masse? I have no clue how to do it except do it and watch out for people to complain. 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?20030506185026.B965>