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

[Daniel Eischen]

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