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
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
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

> > 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?)