From owner-freebsd-arch@FreeBSD.ORG Tue May 6 21:41:09 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 09F9637B40A; Tue, 6 May 2003 21:41:09 -0700 (PDT) Received: from heron.mail.pas.earthlink.net (heron.mail.pas.earthlink.net [207.217.120.189]) by mx1.FreeBSD.org (Postfix) with ESMTP id 48A7643FA3; Tue, 6 May 2003 21:41:08 -0700 (PDT) (envelope-from tlambert2@mindspring.com) Received: from pool0555.cvx40-bradley.dialup.earthlink.net ([216.244.44.45] helo=mindspring.com) by heron.mail.pas.earthlink.net with asmtp (SSLv3:RC4-MD5:128) (Exim 3.33 #1) id 19DGjr-0006St-00; Tue, 06 May 2003 21:41:07 -0700 Message-ID: <3EB88E0D.D8AA9B2F@mindspring.com> Date: Tue, 06 May 2003 21:39:41 -0700 From: Terry Lambert X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: "Jacques A. Vidrine" References: <20030505225021.GA43345@nagual.pp.ru> <20030505232012.GC21953@madman.celabo.org> <20030506152542.GC77708@madman.celabo.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-ELNK-Trace: b1a02af9316fbb217a47c185c03b154d40683398e744b8a476c10568b29f5f064e8d1e8ad765b843a8438e0f32a48e08350badd9bab72f9c350badd9bab72f9c 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: Wed, 07 May 2003 04:41:09 -0000 "Jacques A. Vidrine" wrote: > On Tue, May 06, 2003 at 09:56:06AM +0200, Harti Brandt wrote: > > There is no guarantee that you 'fix' the port by hiding the symbol. You > > 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. > > 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? Have you looked at the "electric fence" port lately? -- Terry