Date: Tue, 18 Mar 2003 08:49:19 +0200
From: "Eli Zaretskii" <eliz AT elta DOT co DOT il>
Sender: halo1 AT zahav DOT net DOT il
To: djgpp-workers AT delorie DOT com
Message-Id: <5137-Tue18Mar2003084918+0200-eliz@elta.co.il>
X-Mailer: emacs 21.3.50 (via feedmail 8 I) and Blat ver 1.8.9
In-reply-to: <3E75E6E1.A3989CD6@yahoo.com> (message from CBFalconer on Mon, 17
	Mar 2003 10:16:49 -0500)
Subject: Re: nmalloc revisited
References: <200303141601 DOT RAA26911 AT lws256 DOT lu DOT erisoft DOT se> <3E721051 DOT 645AA67D AT yahoo DOT com> <3E74B558 DOT 3629CBA9 AT yahoo DOT com> <1438-Sun16Mar2003203300+0200-eliz AT elta DOT co DOT il> <3E74E454 DOT BC734243 AT yahoo DOT com> <3E753E85 DOT 81830981 AT phekda DOT freeserve DOT co DOT uk> <3E755250 DOT 837B3606 AT yahoo DOT com> <3E75B36C DOT 6327581D AT phekda DOT freeserve DOT co DOT uk> <3E75E6E1 DOT A3989CD6 AT yahoo DOT com>
Reply-To: djgpp-workers AT delorie DOT com
Errors-To: nobody AT delorie DOT com
X-Mailing-List: djgpp-workers AT delorie DOT com
X-Unsubscribes-To: listserv AT delorie DOT com
Precedence: bulk

> Date: Mon, 17 Mar 2003 10:16:49 -0500
> From: CBFalconer <cbfalconer AT yahoo DOT com>
> > 
> > The __libc_malloc_fail_hook would be called, if the realloc call were actually
> > failing. So you can find out whether realloc fails, but not in the realloc
> > hook itself.
> 
> There is a big fallacy here - i.e. that malloc and free are
> actually called.

The hooks could be called, in the proper places, even if their
``parent'' functions are not.  That is, even if realloc doesn't call
malloc, the malloc hook could be called where realloc produces the new
block, and malloc-fail hook could be called if realloc or one of its
subroutines fail.

In any case, some actual use of those hooks is required to make
meaningful judgement about their utility.  The only use that I know
of is the implementation of malloc-debug API (which was the original
motivation for adding the hooks); that implementation did not need
any special info about realloc's so the hooks in that area might need
further work.  Only some real-life use will tell.

> Also the "4 bytes" is not accurate, and makes an unwarrented
> connection to the actual implementation.

Of course it does!  The libc documentation is not an abstract standard
document, it documents the specific implementation.  So it should
mention any details that are important for the user of these
functions.  If the implementation changes, the docs should be amanded
as well.

> Look at the description of malloc_debug, for example.  It is full
> of implementation details

That's intended, see above for the rationale.

> and lacking in functional details.  Are
> the reports to stdout, stderr, or some logging file?  I take the
> last back - it does say stderr.

So what functional details _are_ missing, actually?  I'd like to
improve the docs as much as possible, so please do provide
constructive criticism.  TIA

> Adding that back would avoid ANY need for 400 kb auxiliary
> storages and intrinsic limits.  

The storage size is tunable without rebuilding the library (via an
environment variable), as the docs explains.  Any implementation will
need some storage to record every allocation.  So I don't understand
what you are saying here in practical terms.