From owner-freebsd-arch@FreeBSD.ORG Thu May 1 12:10:30 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 3048E37B401; Thu, 1 May 2003 12:10:30 -0700 (PDT) Received: from gw.nectar.cc (gw.nectar.cc [208.42.49.153]) by mx1.FreeBSD.org (Postfix) with ESMTP id 356AF43F93; Thu, 1 May 2003 12:10:29 -0700 (PDT) (envelope-from nectar@celabo.org) Received: from madman.celabo.org (madman.celabo.org [10.0.1.111]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (Client CN "madman.celabo.org", Issuer "celabo.org CA" (verified OK)) by gw.nectar.cc (Postfix) with ESMTP id A7EB569; Thu, 1 May 2003 14:10:28 -0500 (CDT) Received: by madman.celabo.org (Postfix, from userid 1001) id E47D978C4A; Thu, 1 May 2003 14:10:27 -0500 (CDT) Date: Thu, 1 May 2003 14:10:27 -0500 From: "Jacques A. Vidrine" To: John Baldwin Message-ID: <20030501191027.GA53801@madman.celabo.org> Mail-Followup-To: "Jacques A. Vidrine" , John Baldwin , freebsd-arch@FreeBSD.org References: <20030501182820.GA53641@madman.celabo.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Url: http://www.celabo.org/ User-Agent: Mutt/1.5.3i-ja.1 cc: freebsd-arch@FreeBSD.org Subject: Re: 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: Thu, 01 May 2003 19:10:30 -0000 On Thu, May 01, 2003 at 02:45:02PM -0400, John Baldwin wrote: > It seems that many people don't think the symbols in libc need > hiding. What is the reason to prevent a user from overriding the > functions used by libc? malloc() and free() are an example you > agree to, and I don't think we should hide things willy-nilly. > There are many uses for overriding symbols in libc that I'm sure > neither of us have thought of. Why artificially limit it? Nothing prevents one from conciously overriding these parts of libc. I'm merely trying to prevent it from happening accidently. Hiding things willy-nilly is indeed not what we should do. There are several reasonable approaches to determining what to hide. (a) Hide all symbols not explicitly defined in ISO C. (b) Ditto, but raise the bar to POSIX. (c) Hide all symbols, except those that are likely to be candidates to be overridden. malloc/free seem to be the only ones here. The reason that it has been willy-nilly to this point is because we have an imperfect mechanism. Why did I pick on strlcpy/strlcat? Well obviously because of the subtle problem with qpopper, but also because these are functions that are often implemented in portable code, right or wrong that may be. (I would likey not have attempted to hide strcpy if that would have been the issue.) Static linking can make these conflicts become apparent, but if you are dynamic linking --- as is usually the case --- these problems stay dormant until they bite you on the ass. This is dangerous behavior and IMHO we should remove the chance for such accidents where possible. It causes no harm to do so. I have now backed out the strlcpy/strlcat commit. Huh, only now do I notice that NetBSD hid strlcpy/strlcat over a year ago in their tree. :-) Cheers, -- Jacques Vidrine . NTT/Verio SME . FreeBSD UNIX . Heimdal nectar@celabo.org . jvidrine@verio.net . nectar@freebsd.org . nectar@kth.se