From owner-cvs-src@FreeBSD.ORG Tue May 22 10:15:39 2007 Return-Path: X-Original-To: cvs-src@freebsd.org Delivered-To: cvs-src@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 5327D16A46E; Tue, 22 May 2007 10:15:39 +0000 (UTC) (envelope-from deischen@freebsd.org) Received: from mail.ntplx.net (mail.ntplx.net [204.213.176.10]) by mx1.freebsd.org (Postfix) with ESMTP id ED44113C484; Tue, 22 May 2007 10:15:38 +0000 (UTC) (envelope-from deischen@freebsd.org) Received: from sea.ntplx.net (sea.ntplx.net [204.213.176.11]) by mail.ntplx.net (8.14.1/8.14.1/NETPLEX) with ESMTP id l4MAFbem001621; Tue, 22 May 2007 06:15:37 -0400 (EDT) X-Virus-Scanned: by AMaViS and Clam AntiVirus (mail.ntplx.net) X-Greylist: Message whitelisted by DRAC access database, not delayed by milter-greylist-3.0 (mail.ntplx.net [204.213.176.10]); Tue, 22 May 2007 06:15:37 -0400 (EDT) Date: Tue, 22 May 2007 06:15:37 -0400 (EDT) From: Daniel Eischen X-X-Sender: eischen@sea.ntplx.net To: Jonathan Chen In-Reply-To: <20070522060432.GF70650@porthos.spock.org> Message-ID: References: <200705220303.l4M33TcW009568@repoman.freebsd.org> <20070522060432.GF70650@porthos.spock.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: cvs-src@freebsd.org, src-committers@freebsd.org, cvs-all@freebsd.org Subject: Re: cvs commit: src/lib/libc/stdlib Symbol.map X-BeenThere: cvs-src@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Daniel Eischen List-Id: CVS commit messages for the src tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 May 2007 10:15:39 -0000 On Tue, 22 May 2007, Jonathan Chen wrote: > On Tue, May 22, 2007 at 12:29:53AM -0400, Daniel Eischen wrote: >> On Tue, 22 May 2007, Daniel Eischen wrote: >> >>> On Tue, 22 May 2007, Jonathan Chen wrote: >>>> Log: >>>> __cleanup() is needed for ports/devel/valgrind, export it. >>> >>> Please revert this. fcloseall() is the interface to use. >> >> And the rule of thumb to use when trying to decide whether to export >> these functions is, does it have a prototype in /usr/include/... > > The change has been backed out, however, I still have some concerns whether > fcloseall() or something else is an appropriate replacement for __cleanup in > valgrind. The main reason for my concern is that fcloseall() is not > equivalent to __cleanup, and valgrind belongs in a special class of > programs where some of its actions should mirror those of libc as closely > as possible. A quick test shows that replacing __cleanup() with > fcloseall() in valgrind can have an effect on valgrind's report of memory > still allocated at program exit. fcloseall() was added so we can remove __cleanup(), and Linux has an fcloseall() also. If fcloseall() isn't functioning correctly, then let's fix it. But it looked like it was doing the same thing as __cleanup(), at least that is what it was suppose to be doing. What does valgrind do for Linux? > Furthermore, the private section of > Symbol.map already exports a number of other "private" functions not > mentioned in /usr/include. Yes, these are needed mostly for our base system, not for ports or things not part of our base. We should try and prevent adding private interfaces just for ports. I know there are a few exceptions, where some ports are using some of these private interfaces. But Kris has run a couple of port runs for me, and there's really not many instances of this. > While I respect the desire to keep libc as clean as possible, I think this > might be a case that warrants an exception. Nevertheless, I'm willing to > be convinced either way. Me too, but the purpose of fcloseall() was to remove references to __cleanup() ;-) -- DE