From owner-cvs-all@FreeBSD.ORG Wed Apr 30 08:36:48 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 DB6A537B401; Wed, 30 Apr 2003 08:36:48 -0700 (PDT) Received: from mx0.freebsd-services.com (survey.codeburst.net [195.149.39.161]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8457643F93; Wed, 30 Apr 2003 08:36:47 -0700 (PDT) (envelope-from paul@freebsd-services.com) Received: by mx0.freebsd-services.com (Postfix, from userid 1002) id 182EE1B211; Wed, 30 Apr 2003 16:36:46 +0100 (BST) Date: Wed, 30 Apr 2003 16:36:45 +0100 From: Paul Richards To: "Jacques A. Vidrine" Message-ID: <20030430153645.GL39658@survey.codeburst.net> 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> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030430152708.GA26216@madman.celabo.org> User-Agent: Mutt/1.4.1i cc: src-committers@FreeBSD.org cc: Daniel Eischen cc: Kris Kennaway cc: cvs-src@FreeBSD.org cc: Dag-Erling Smorgrav cc: cvs-all@FreeBSD.org cc: "W. Josephson" 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:36:49 -0000 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. 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. strlcpy is part of the "FreeBSD libc" since it's a documented interface for application writers to use. 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. -- Paul Richards