From owner-freebsd-arch@FreeBSD.ORG Tue May 6 10:01:07 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 55E7537B401; Tue, 6 May 2003 10:01:07 -0700 (PDT) Received: from mailhub.fokus.fraunhofer.de (mailhub.fokus.fraunhofer.de [193.174.154.14]) by mx1.FreeBSD.org (Postfix) with ESMTP id A8EE643FAF; Tue, 6 May 2003 10:01:05 -0700 (PDT) (envelope-from brandt@fokus.fraunhofer.de) Received: from beagle (beagle [193.175.132.100])h46H14E05835; Tue, 6 May 2003 19:01:04 +0200 (MEST) Date: Tue, 6 May 2003 19:00:05 +0200 (CEST) From: Harti Brandt To: "Jacques A. Vidrine" In-Reply-To: <20030506161732.GB78486@madman.celabo.org> Message-ID: <20030506185026.B965@beagle.fokus.fraunhofer.de> References: <20030501182820.GA53641@madman.celabo.org> <20030505175426.GA19352@madman.celabo.org> <20030506092519.GA3158@cirb503493.alcatel.com.au> <20030506153641.GI77708@madman.celabo.org> <20030506161732.GB78486@madman.celabo.org> 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: Tue, 06 May 2003 17:01:07 -0000 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