From owner-freebsd-arch@FreeBSD.ORG Tue May 6 22:39:56 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 CCE7037B401; Tue, 6 May 2003 22:39:56 -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 2247543F3F; Tue, 6 May 2003 22:39:54 -0700 (PDT) (envelope-from tlambert2@mindspring.com) Received: from pool0555.cvx40-bradley.dialup.earthlink.net ([216.244.44.45] helo=mindspring.com) by puffin.mail.pas.earthlink.net with asmtp (SSLv3:RC4-MD5:128) (Exim 3.33 #1) id 19DHei-0000eS-00; Tue, 06 May 2003 22:39:53 -0700 Message-ID: <3EB89BD6.4F1C0807@mindspring.com> Date: Tue, 06 May 2003 22:38:30 -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: <20030501182820.GA53641@madman.celabo.org> <20030503201409.GA41554@dragon.nuxi.com> <20030505175428.GA19275@madman.celabo.org> <20030506175557.GE79167@madman.celabo.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-ELNK-Trace: b1a02af9316fbb217a47c185c03b154d40683398e744b8a463878834c50389609f5005f41b0c182f350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c cc: David O'Brien 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 05:39:57 -0000 "Jacques A. Vidrine" wrote: > > > Do you also want to `fix' the other ports that define their own strlcpy? > > > > Ports have maintainers. Please create a PR for them. > > But gee, the problem is that the ports themselves are not really > in error, unless one is a standards fascist that believes that an > application can never define any function that might be in some > standard's namespace. I'm a standards faciest, though I'm usually pretty lenient about it, unless it comes to obvious bugs like code not using pthreads_mutex'es where required by the standard. And I think the problem can happen, even though the ports may not be in error. Consider: the linker sees symbols defined in libc, even if the compiler doesn't because of all the namespace voodoo having been done precisely correctly in the application. There are also a number of libc functions which are defined by a newer standard but not an older one, which are used internally to implement functions defined in both the older and newer standards, such that if the port is compliant with the older standard, has it's namespace ducks all in a row, and carries around it's own copy of the newer function, it will cause functions in the standard with which it complies to fail. In other words, just because the compiler can't see it, does not mean the linker won't. It's probably impossible to resolve this completely, without more linker-foo and compiler-foo than I'm willing to contemplate to make the linker aware of the standards used by the compiler. God help you, if you have a program that depends on a third party library that depends on a system library... -- Terry