Date: Tue, 6 May 2003 11:43:13 +0200 (CEST) From: Harti Brandt <brandt@fokus.fraunhofer.de> To: Peter Jeremy <peterjeremy@optushome.com.au> Cc: freebsd-arch@freebsd.org Subject: Re: Re: `Hiding' libc symbols Message-ID: <20030506112711.K838@beagle.fokus.fraunhofer.de> In-Reply-To: <20030506092519.GA3158@cirb503493.alcatel.com.au> References: <20030501182820.GA53641@madman.celabo.org> <XFMail.20030501144502.jhb@FreeBSD.org> <20030505175426.GA19352@madman.celabo.org> <20030506092519.GA3158@cirb503493.alcatel.com.au>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 6 May 2003, Peter Jeremy wrote: PJ>On Tue, May 06, 2003 at 09:46:12AM +0200, Harti Brandt wrote: PJ>>On Mon, 5 May 2003, Jacques A. Vidrine wrote: PJ>>JAV>So, I advocate hiding all symbols in libc by default. The Real World PJ>>JAV>doesn't seem to care whether the symbols are defined by any standard or PJ>>JAV>not. PJ>> PJ>>No. If I define my own printf() I want that printf to be called even by PJ>>library internal calls. PJ> PJ>What if I define my own printf() that doesn't fully implement all the PJ>functionality of the FreeBSD printf()? It works meets all the requirements PJ>for my code (and maybe even runs correctly elsewhere) but doesn't work PJ>on FreeBSD because a library internal call (hypothetically) relies on PJ>functionality that I don't need. That's the fault of the application. When I replace a standard defined function I have to know what I do. The problem with printf and the entire stdio stuff is, that it has interdependencies between several functions. These come from using macros in stdio.h and using internal interfaces between these library functions. If a library function calls the librarie's printf it will end up in __svfwrite which knows the internals of how an i/o stream works. The application's replacement may function differently, it's printf may be based on calls to write() using fileno() or it may replace the entire stdio. In either case the application will simply not work. Here I have to support Terry's statement that replacing libc symbols has a long history and allows you to do things, that otherwise will be impossible or much harder. PJ>This is most likely to surface in functions like strlcpy(), strlcat() PJ>and snprintf() where the return value includes a reference to the PJ>size of the buffer that would be required to perform the requested PJ>operation without truncation. This is the most likely area where an PJ>implementor may cut corners if hir application does not rely on the PJ>return value. PJ> PJ>>The situation may be different for non-standardized functions with names PJ>>in the application space like err(). PJ> PJ>Last time I checked, the base system included a program that included its PJ>own err() function - with functionality substantially different to err(3). To say it otherwise: I think hiding names that are not in Posix/Ansi is a good thing, because we must assume, that applications have functions with the same names doing entirely different things. Hiding names that are not standardized functions, but are in the standard or implementation namespace is probably a good thing to do too. Hiding functions that are in the standards is a bad thing. If applications use these names, we should assume that the function does at least what the standard requires. If not the application is broken and must be fixed. Otherwise we will break an unknown number of applications. In your example: err() is a function from the first class, so hiding it would appropriate. (And I should say, that my pdp11 emulator suffered from exactly this problem: it had an err() function with a different arguments than that in libc. I had to replace it with a different name.) 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?20030506112711.K838>