From owner-freebsd-arch@FreeBSD.ORG Tue May 6 11:00:50 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 5FCB837B401; Tue, 6 May 2003 11:00:50 -0700 (PDT) Received: from mail.tcoip.com.br (erato.tco.net.br [200.220.254.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3732343F85; Tue, 6 May 2003 11:00:46 -0700 (PDT) (envelope-from dcs@tcoip.com.br) Received: from tcoip.com.br ([10.0.2.6]) by mail.tcoip.com.br (8.11.6/8.11.6) with ESMTP id h46I0f928475; Tue, 6 May 2003 15:00:41 -0300 Message-ID: <3EB7F85A.5070500@tcoip.com.br> Date: Tue, 06 May 2003 15:00:58 -0300 From: "Daniel C. Sobral" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.3) Gecko/20030312 X-Accept-Language: en-us, en, pt-br, ja MIME-Version: 1.0 To: "Jacques A. Vidrine" References: <20030505225021.GA43345@nagual.pp.ru> <20030505232012.GC21953@madman.celabo.org> <20030506095424.G838@beagle.fokus.fraunhofer.de> <20030506152542.GC77708@madman.celabo.org> In-Reply-To: <20030506152542.GC77708@madman.celabo.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable cc: "Andrey A. Chernov" cc: Daniel Eischen cc: freebsd-arch@freebsd.org Subject: 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 18:00:50 -0000 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