Date: Tue, 6 May 2003 17:49:53 +0200 (CEST) From: Harti Brandt <brandt@fokus.fraunhofer.de> To: "Jacques A. Vidrine" <nectar@FreeBSD.org> Cc: freebsd-arch@FreeBSD.org Subject: Re: `Hiding' libc symbols Message-ID: <20030506173822.A631@beagle.fokus.fraunhofer.de> In-Reply-To: <20030506152542.GC77708@madman.celabo.org> References: <20030505225021.GA43345@nagual.pp.ru> <Pine.GSO.4.10.10305051855570.10283-100000@pcnet1.pcnet.com> <20030506095424.G838@beagle.fokus.fraunhofer.de> <20030506152542.GC77708@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 09:56:06AM +0200, Harti Brandt wrote: JAV>> There is no guarantee that you 'fix' the port by hiding the symbol. You JAV>> may as well break it. This depends on the function itself and on the JAV>> internal relationships in libc. You have to go through each individual JAV>> port and see what happens anyway. JAV> JAV>Please explain. I _am_ guaranteed that keeping the port from hijacking JAV>strlcpy calls in libc will not break the port. How could the port rely JAV>on the internals of libc? Well, strlcpy is not a very interesting example because it stand on its own. More interesting are examples where library functions depend on each other (malloc/free, fopen and co.) The user calls its own malloc(), the library tries to free with its own free(). The application could replace *printf() to actually redirect output... At the end the port might have its own strlcpy to track buffers it has written to for whatever reason. 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?20030506173822.A631>