From owner-cvs-src@FreeBSD.ORG Wed Apr 30 09:41:41 2003 Return-Path: Delivered-To: cvs-src@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A14C237B404; Wed, 30 Apr 2003 09:41:41 -0700 (PDT) Received: from gw.nectar.cc (gw.nectar.cc [208.42.49.153]) by mx1.FreeBSD.org (Postfix) with ESMTP id B1D5543FB1; Wed, 30 Apr 2003 09:41:37 -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 034694; Wed, 30 Apr 2003 11:41:37 -0500 (CDT) Received: by madman.celabo.org (Postfix, from userid 1001) id 18EBC78C4A; Wed, 30 Apr 2003 11:41:36 -0500 (CDT) Date: Wed, 30 Apr 2003 11:41:35 -0500 From: "Jacques A. Vidrine" To: Paul Richards , "W. Josephson" Message-ID: <20030430164135.GB26508@madman.celabo.org> Mail-Followup-To: "Jacques A. Vidrine" , Paul Richards , "W. Josephson" , freebsd-arch@FreeBSD.org References: <20030430004907.GA32349@mero.morphisms.net> <20030430031856.GA20258@madman.celabo.org> <20030430144149.GA7786@dragon.nuxi.com> <20030430002014.GA1190@dragon.nuxi.com> <20030430043303.GA46365@mero.morphisms.net> <20030430062647.GA82023@rot13.obsecurity.org> <20030430143121.GK39658@survey.codeburst.net> <20030430152708.GA26216@madman.celabo.org> <20030430153645.GL39658@survey.codeburst.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030430154936.GA58835@mero.morphisms.net> <20030430153645.GL39658@survey.codeburst.net> X-Url: http://www.celabo.org/ User-Agent: Mutt/1.5.3i-ja.1 X-Mailman-Approved-At: Wed, 30 Apr 2003 12:03:18 -0700 cc: freebsd-arch@FreeBSD.org Subject: `Hiding' libc symbols (was Re: cvs commit: src/lib/libc/gen ...) X-BeenThere: cvs-src@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: CVS commit messages for the src tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Apr 2003 16:41:43 -0000 [Trimmed cc:list; moving to freebsd-arch] First, has something been broken by making strlcpy/strlcat into a weak reference? Second, for the sake of discussion only, let us assume that (a) we like users, and we want users to use FreeBSD; and (b) we like developers, and we want developers to write software on FreeBSD. Then, let's consider an exercise. Take two software packages: Package X defines a function named `strlcpy', that works well for Package X and may or may not have any relationship to the `strlcpy' we all know and love from OpenBSD. Package Y utilizes strlcpy. It does not define it, but makes the fairly reasonable assumption that the platform provides a working strlcpy with the (now) well-known semantics from OpenBSD. Which of the following scenarios is the least astonishing? Scenario 1. Package X builds and runs, but blows up in certain libc functions. Package Y builds and runs correctly. Scenario 2. Package X builds and runs correctly. Package Y builds, but only if you link it with the rather non-standard `libkitchen_sink'. The image of Package Y is also bigger than on other platforms, because it has two implementations of strlcpy (the one used internally in libc, and the one from libkitchen_sink). Scenario 3. Package X and Package Y both build and run correctly. Guess which scenario applied before my commit to make strlcpy/strlcat weak references? which applies now? which would apply if we broke strlcpy/strlcat into another library? For bonus points, extend the example with Package Z, which uses `strlcpy' but only defines it if it doesn't detect it as implemented on the platform. Maybe multiply the instances of applications such as Package X, Y, and Z by 8000 or so --- how does that affect the issue? Third, specific comments below if you are not bored yet. On Wed, Apr 30, 2003 at 04:36:45PM +0100, Paul Richards wrote: > On Wed, Apr 30, 2003 at 10:27:08AM -0500, Jacques A. Vidrine wrote: > > > > We have no business exporting symbols from libc that are not described > > by any standard. We have no business assuming that if an application > > defines a function called `strlcpy' that it resembles, in intent or in > > actual implementation, our own strlcpy. > > That's an orthogonal issue really, since libc is not a "pure" > implementation of the standard C library, it also includes a number of > extensions that have been bundled into our libc because it's sometimes > a convenient dumping ground. I don't see how you can call that `orthogonal'... that is the root of the issue we are discussing. > Hiding functions that aren't meant to be exported would make sense, > but hiding functions that are intended to be exported but aren't > part of the standard is not so useful. How is it not useful? It is useful for qpopper. It is useful for isc-dhcp. > strlcpy is part of the "FreeBSD libc" since it's a documented interface > for application writers to use. Oh, of course. I forgot that we only support applications written for FreeBSD. I thought we should be a decent platform for ISO C and POSIX applications as well, but that is clearly foolishness. > The alternative is to split out these functions and keep libc pure, and > then link them into our applications if we use them. This is an approach > other platforms have taken but one we've not gone down because of the > proliferation of libraries that then have to be included when writing > apps. What are these other platforms? Could you elaborate on what exactly they are doing that you think we should emulate? There are platforms with `strlcpy' in the base system, but not in libc? There are platforms that have _no_ functions in libc that are not in ISO C? in POSIX? If we were to decide to make such a split, what functions would be OK for libc? Which standard will we take as authoritative? Only ISO C functions? Only POSIX functions? Which options in POSIX? etc On Wed, Apr 30, 2003 at 11:49:36AM -0400, W. Josephson wrote: > On Wed, Apr 30, 2003 at 10:27:08AM -0500, Jacques A. Vidrine wrote: > > We have no business exporting symbols from libc that are not described > > by any standard. We have no business assuming that if an application > > defines a function called `strlcpy' that it resembles, in intent or in > > actual implementation, our own strlcpy. > > Then we should not export functions used internally that aren't > a part of the standards at all and put functions such as strlcpy > that are explicitly exported by design in a different library, no? No, I don't think so. 1) We break the build of many applications if we move commonly- used interface into some new library. 2) We add an annoying difference with other platforms that also implement these commonly-used interfaces. 3) We add code bloat. These commonly-used interfaces are used within libc and within applications. If we split them out into separate libraries, then applications will carry around twice the code. > > return value from our strlcpy. Is it a bug in that application if it > > cannot use parts of libc because of this? No. It is a bug in our > > libc. > > I think this is a separate issue from what gave rise to the > discussion. What is a separate issue? This is _the_ issue. > I still believe it is a mistake to play games with > symbols explicitly exported by libc. Either the symbols should be > exported normally or they shouldn't be exported at all: Think through the consequences of this. e.g. If we did not export `warn' using a weak reference, then dhclient could not be compiled statically on FreeBSD. If we did not export `warn' at all, then we would need to put `warn' in a separate library and break lots of code. > keeping track > of which platform does what with which functions, be they standard > functions or common extensions, just makes life harder for everyone as > far as I can tell. But that is what it sounds like you are suggesting. ``Oh, I forgot, to use strlcpy on FreeBSD, I must add `-lfreebsd', how lame.'' Cheers, -- Jacques Vidrine . NTT/Verio SME . FreeBSD UNIX . Heimdal nectar@celabo.org . jvidrine@verio.net . nectar@freebsd.org . nectar@kth.se