Date: Tue, 22 May 2007 02:04:32 -0400 From: Jonathan Chen <jon@freebsd.org> To: Daniel Eischen <deischen@freebsd.org> Cc: cvs-src@freebsd.org, src-committers@freebsd.org, cvs-all@freebsd.org Subject: Re: cvs commit: src/lib/libc/stdlib Symbol.map Message-ID: <20070522060432.GF70650@porthos.spock.org> In-Reply-To: <Pine.GSO.4.64.0705220025430.1944@sea.ntplx.net> References: <200705220303.l4M33TcW009568@repoman.freebsd.org> <Pine.GSO.4.64.0705220023030.1944@sea.ntplx.net> <Pine.GSO.4.64.0705220025430.1944@sea.ntplx.net>
next in thread | previous in thread | raw e-mail | index | archive | help
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:
> >
> >>jon 2007-05-22 03:03:29 UTC
> >>
> >> FreeBSD src repository
> >>
> >> Modified files:
> >> lib/libc/stdlib Symbol.map
> >> 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. Furthermore, the private section of
Symbol.map already exports a number of other "private" functions not
mentioned in /usr/include.
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.
--
(o_ 1-2-1-2-1-2-1-2-1-2-1-2-1-2-1-2-1-2-1-2-1-2-1-2-1-2-1-2-1-2 _o)
\\\_\ Jonathan Chen jon@spock.org /_///
<____) No electrons were harmed during production of this message (____>
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20070522060432.GF70650>