Date: Tue, 18 Mar 2003 08:37:13 +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: <8296-Tue18Mar2003083713+0200-eliz@elta.co.il>
X-Mailer: emacs 21.3.50 (via feedmail 8 I) and Blat ver 1.8.9
In-reply-to: <3E755250.837B3606@yahoo.com> (message from CBFalconer on Sun, 16
	Mar 2003 23:42:56 -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>
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: Sun, 16 Mar 2003 23:42:56 -0500
> From: CBFalconer <cbfalconer AT yahoo DOT com>
> 
> For example, the existing realloc hook has no way of telling what
> the result of realloc was.

The other hooks that get called inside realloc and its subroutines do
that job.

> In addition the specifications have magic numbers, which
> have no relationship to reality for this system.

What magic numbers?  If you mean the 4-byte overhead and such, then
the documentation mentions that because it tries to give all the
details pertinent to debugging malloc-related issues.  If the details
of your implementation are different, you should revise the
documentation accordingly.  There's no intent, of course, to insist on
4-byte overhead/offset in an implementation that manages the memory
pool in a different way.

> Nobody has confirmed or denied that the html doc file I fed back
> earlier really covers the subject.

Sorry, I don't have time to open binary attachments and/or launching a
Web browser to read them.  Could you possibly send that as plain text
that is part of the message body?  Then I promise I'll read and
respond.

TIA

> I have modified (but not published yet) nmalloc to allow use of
> the HOOKABLE define, which basically modifies the access points
> from malloc to _malloc, etc.

I'm not sure renaming standard functions is a good idea.  There are
development tools out there (e.g., GDB) that _depend_ on their
knowledge of some of these fucntions.  If we have __malloc instead of
_malloc in our symbol table, these tools might become confused.

Isn't there some other way of providing hooks?