Message-ID: <3E771522.8B7EDA55@yahoo.com>
Date: Tue, 18 Mar 2003 07:46:26 -0500
From: CBFalconer <cbfalconer AT yahoo DOT com>
Organization: Ched Research
X-Mailer: Mozilla 4.75 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: djgpp-workers AT delorie DOT com
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> <8296-Tue18Mar2003083713+0200-eliz AT elta DOT co DOT il>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Reply-To: djgpp-workers AT delorie DOT com

Eli Zaretskii wrote:
> > From: CBFalconer <cbfalconer AT yahoo DOT com>
> >
... snip ...
> 
> > 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?

I would be glad to try something else, if anyone can propose it. 
Meanwhile note that the _malloc name etc are limited to the files
hookmem.h, malldbg.c, and (only when HOOKABLE is defined)
nmalloc.c.  The three names are easily changed to something else
if conflicts arise.  They do not propagate onward, except as the
linker handles them.  Eventually the two .c files can be combined,
with the malldbg portion enabled only by HOOKABLE, and the name
pollution can disappear.

Meanwhile the purpose is to avoid disturbing proven (to me) code
with new code.

As far as the realloc hooks are concerned, nmalloc NEVER calls
free or its equivalent in many circumstances, even when the
contents are moved.  It also never calls malloc.  Any such
indication would be a distortion.  Thus I am providing a
realloc_exit hook, when the net effect can be detected.  The
internal tables are already consistent.  Something external is
free to assume that the original is freed and the new malloced,
although that does not reflect reality.

-- 
Chuck F (cbfalconer AT yahoo DOT com) (cbfalconer AT worldnet DOT att DOT net)
   Available for consulting/temporary embedded and systems.
   <http://cbfalconer.home.att.net>  USE worldnet address!