Date: Tue, 06 May 2003 15:00:58 -0300 From: "Daniel C. Sobral" <dcs@tcoip.com.br> To: "Jacques A. Vidrine" <nectar@freebsd.org> Cc: freebsd-arch@freebsd.org Subject: Re: `Hiding' libc symbols Message-ID: <3EB7F85A.5070500@tcoip.com.br> In-Reply-To: <20030506152542.GC77708@madman.celabo.org> References: <20030505225021.GA43345@nagual.pp.ru> <Pine.GSO.4.10.10305051855570.10283-100000@pcnet1.pcnet.com> <20030505232012.GC21953@madman.celabo.org> <20030506095424.G838@beagle.fokus.fraunhofer.de> <20030506152542.GC77708@madman.celabo.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Jacques A. Vidrine wrote: > On Tue, May 06, 2003 at 09:56:06AM +0200, Harti Brandt wrote: >=20 >>There is no guarantee that you 'fix' the port by hiding the symbol. Yo= u >>may as well break it. This depends on the function itself and on the >>internal relationships in libc. You have to go through each individual >>port and see what happens anyway. >=20 >=20 > Please explain. I _am_ guaranteed that keeping the port from hijacking= > strlcpy calls in libc will not break the port. How could the port rely= > on the internals of libc? Well... if I instrument all memory allocating functions (by providing my = own copies) and I call a function that allocates memory by itself and=20 expects my application to free that memory at some point, I expect the=20 kernel to use one of my functions to do it. --=20 Daniel C. Sobral Ger=EAncia de Opera=E7=F5es Divis=E3o de Comunica=E7=E3o de Dados Coordena=E7=E3o de Seguran=E7a VIVO Centro Oeste Norte Fones: 55-61-313-7654/Cel: 55-61-9618-0904 E-mail: Daniel.Capo@tco.net.br Daniel.Sobral@tcoip.com.br dcs@tcoip.com.br
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3EB7F85A.5070500>