From owner-freebsd-arch@FreeBSD.ORG Tue May 6 07:56:00 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 5E98937B401 for ; Tue, 6 May 2003 07:56:00 -0700 (PDT) Received: from puffin.mail.pas.earthlink.net (puffin.mail.pas.earthlink.net [207.217.120.139]) by mx1.FreeBSD.org (Postfix) with ESMTP id B98EA43FB1 for ; Tue, 6 May 2003 07:55:59 -0700 (PDT) (envelope-from tlambert2@mindspring.com) Received: from pool0297.cvx40-bradley.dialup.earthlink.net ([216.244.43.42] helo=mindspring.com) by puffin.mail.pas.earthlink.net with asmtp (SSLv3:RC4-MD5:128) (Exim 3.33 #1) id 19D3rG-00079R-00; Tue, 06 May 2003 07:55:54 -0700 Message-ID: <3EB7CC73.9C61C27E@mindspring.com> Date: Tue, 06 May 2003 07:53:39 -0700 From: Terry Lambert X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Peter Jeremy References: <20030501182820.GA53641@madman.celabo.org> <20030505110601.H53365@beagle.fokus.fraunhofer.de> <20030505175426.GA19352@madman.celabo.org> <20030506092519.GA3158@cirb503493.alcatel.com.au> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-ELNK-Trace: b1a02af9316fbb217a47c185c03b154d40683398e744b8a4cd605700a281f5a66db403488a789133a7ce0e8f8d31aa3f350badd9bab72f9c350badd9bab72f9c 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 14:56:00 -0000 Peter Jeremy wrote: > What if I define my own printf() that doesn't fully implement all the > functionality of the FreeBSD printf()? It works meets all the requirements > for my code (and maybe even runs correctly elsewhere) but doesn't work > on FreeBSD because a library internal call (hypothetically) relies on > functionality that I don't need. This is actually a library implementation problem, related to incestuous implementation of library calls. If another library function doesn't use e.g. strlcpy() internally, then it will not be effected by an application replacing strlcpy(). It's only when a library function depends on another library function, rather than itself, that it's at risk for this type of failure. Perhaps instead of asking how to prevent symbol replacement, one should be asking how to get rid of incestuous functions in the library implementation for standard library functions. No, I do not expect "_fmt" (or whatever) to go away from common code in printf/sprintf/whatever. But I do expect it to be "_fmt" instead of "fmt", i.e. in implementation space, rather than in the symbol space legal for users to use. -- Terry