cvs commit: src/lib/libc/stdlib Symbol.map

[Jonathan Chen]

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 at spock.org           /_///
 <____)  No electrons were harmed during production of this message (____>
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~