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
_______________________________________________
[email protected] mailing list
http://lists.freebsd.org/mailman/listinfo/cvs-all
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Reply via email to