From:	sandmann AT clio DOT rice DOT edu (Charles Sandmann)
Message-Id:	<10303181608.AA14409@clio.rice.edu>
Subject:	Re: nmalloc revisited
To:	djgpp-workers AT delorie DOT com
Date:	Tue, 18 Mar 2003 10:08:59 -0600 (CST)
In-Reply-To:	<3E771522.8B7EDA55@yahoo.com> from "CBFalconer" at Mar 18, 2003 07:46:26 AM
X-Mailer:	ELM [version 2.5 PL2]
Mime-Version:	1.0
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

> > 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.

I would say even more strongly it's a bad idea, since we need to work
with libraries which source may not be readily available, but you
need to know if their use of malloc() is causing problems. 

> > 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.

This must be a run time option, not a compile time option.  What's
the problem with the hooks the library currently uses (adding them
to the nmalloc code?)

- Raw text -