From owner-cvs-all@FreeBSD.ORG Tue Apr 29 21:27:26 2003 Return-Path: Delivered-To: cvs-all@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 19B1537B401; Tue, 29 Apr 2003 21:27:26 -0700 (PDT) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0048D43FBD; Tue, 29 Apr 2003 21:27:25 -0700 (PDT) (envelope-from eischen@pcnet1.pcnet.com) Received: from pcnet1.pcnet.com (localhost [127.0.0.1]) by mail.pcnet.com (8.12.8/8.12.1) with ESMTP id h3U4RNBg002752; Wed, 30 Apr 2003 00:27:24 -0400 (EDT) Received: from localhost (eischen@localhost)h3U4RMuD002725; Wed, 30 Apr 2003 00:27:22 -0400 (EDT) Date: Wed, 30 Apr 2003 00:27:22 -0400 (EDT) From: Daniel Eischen To: src-committers@FreeBSD.org, cvs-src@FreeBSD.org, cvs-all@FreeBSD.org In-Reply-To: <20030430002014.GA1190@dragon.nuxi.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: Jacques Vidrine cc: Dag-Erling Smorgrav Subject: Re: cvs commit: src/lib/libc/gen check_utility_compat.c confstr.c un-namespace.hgethostbydns.c getnameinfo.c hesiod.c ... X-BeenThere: cvs-all@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: CVS commit messages for the entire tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Apr 2003 04:27:26 -0000 On Tue, 29 Apr 2003, David O'Brien wrote: > On Tue, Apr 29, 2003 at 11:49:09PM +0200, Dag-Erling Smorgrav wrote: > > Jacques Vidrine writes: > > > Log: > > > `Hide' strlcpy and strlcat (using the namespace.h / __weak_reference > > > technique) so that we don't wind up calling into an application's > > > version if the application defines them. > > > > We should probably do this for every libc function that is used within > > libc... > > No we shouldn't. If I understand you correctly, it prevents me from > linking in my own malloc()/free() and having the entire system use it. > Being able to replace the use of a libc function for *all* running of a > program is a very useful thing. Why can't you still do this? You just have to know the real name of the function you want to override. Is malloc any different than _malloc, so that you can't supply your own with the correct symbol? -- Dan Eischen