Date: Tue, 6 May 2003 09:46:12 +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: <20030506093754.B838@beagle.fokus.fraunhofer.de> In-Reply-To: <20030505175426.GA19352@madman.celabo.org> References: <20030501182820.GA53641@madman.celabo.org> <XFMail.20030501144502.jhb@FreeBSD.org> <20030505110601.H53365@beagle.fokus.fraunhofer.de> <20030505175426.GA19352@madman.celabo.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 5 May 2003, Jacques A. Vidrine wrote: JAV>On Mon, May 05, 2003 at 11:14:17AM +0200, Harti Brandt wrote: JAV>> On Thu, 1 May 2003, Jacques A. Vidrine wrote: JAV>> JAV>Some of these applications really want to override the functions for JAV>their own purposes, like arts which overrides the hidden `open' stub. JAV>Note that these applications work just fine even though the symbols are JAV>`hidden' ... that is not the issue. JAV> JAV>The rest of the applications seem to be defining their own versions of JAV>some functions for portability purposes. Defining `printf' seems pretty JAV>funny, but J. Schilling is not the only author who has done so. JAV>In these cases, it seems dangerous to have libc calling into the JAV>application's implementation, e.g. calling Mozilla's `mkstemp' in order JAV>to implement `hashopen', or calling Smiley's `bsearch' in order to JAV>implement `nsdispatch', or calling MySQL's `strstr' to implement JAV>`syslog' and so on and on. JAV> JAV>So, I advocate hiding all symbols in libc by default. The Real World JAV>doesn't seem to care whether the symbols are defined by any standard or JAV>not. No. If I define my own printf() I want that printf to be called even by library internal calls. This is even more obvious, for example, for things like stdio where it would simply not work when the library calls its own fputc() and the application calls its application defined fputc(). The same holds for printf() that may use private interfaces into stdio. These will not work if the file was opened with the applications fopen(). The situation may be different for non-standardized functions with names in the application space like err(). It is certainly unwise to require that no application should define err() so that it wont conflict with our library's err(). In these cases it may make really sense to hide this functions. 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?20030506093754.B838>