From owner-cvs-all@FreeBSD.ORG Wed Apr 30 08:19:18 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 AD18437B401; Wed, 30 Apr 2003 08:19:18 -0700 (PDT) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9409243FDD; Wed, 30 Apr 2003 08:19:17 -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 h3UFJABg006120; Wed, 30 Apr 2003 11:19:10 -0400 (EDT) Received: from localhost (eischen@localhost)h3UFJ9oZ006117; Wed, 30 Apr 2003 11:19:09 -0400 (EDT) Date: Wed, 30 Apr 2003 11:19:09 -0400 (EDT) From: Daniel Eischen To: Paul Richards In-Reply-To: <20030430143121.GK39658@survey.codeburst.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: cvs-src@FreeBSD.org cc: src-committers@FreeBSD.org cc: "W. Josephson" cc: cvs-all@FreeBSD.org cc: Kris Kennaway 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 15:19:19 -0000 On Wed, 30 Apr 2003, Paul Richards wrote: > On Tue, Apr 29, 2003 at 11:26:47PM -0700, Kris Kennaway wrote: > > On Wed, Apr 30, 2003 at 12:33:03AM -0400, W. Josephson wrote: > > > On Wed, Apr 30, 2003 at 12:27:22AM -0400, Daniel Eischen wrote: > > > > 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? > > > > > > It is just one more thing to hack around on > > > every platform. I still don't understand > > > why the urge to make things more complicated > > > for the sake of admittedly broken software. > > > Why not just fix the bug at its source rather > > > than making life more difficult for stuff that > > > is written correctly? > > > > Because the source is not always available. Fortunately, for qpopper > > it is, but as Jacques stated in another message there is a chance that > > other binary applications also do this. > > Hiding our libc implementation is the wrong approach here. I think the > strlcpy hiding should be taken out. There's another problem here. We *should* be hiding symbols that become exposed to application namespace (through no fault of the application) if they are not part of a relevent spec. strlcpy doesn't seem to be part of POSIX; is there some other standard to which it belongs? If not, and our libc is using them internally or they are becoming unexpectedly exposed some other way, then they need to be hidden. -- Dan Eischen