Message-ID:	<3E77500F.7C09422@yahoo.com>
Date:	Tue, 18 Mar 2003 11:57:51 -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:	<10303181608 DOT AA14409 AT clio DOT rice DOT edu>
Reply-To:	djgpp-workers AT delorie DOT com

Charles Sandmann wrote:
> 
... snip ...
> >
> > 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?)

When everything works for the debuggery, that is perfectly
possible as described above.  However there is always going to be
namespace pollution, and the only way I see to eliminate it is
with separate modules, one of which has only malloc, free,
realloc, and the other has whatever else is needed.  That is why I
chose the separarate sysquery.h header and _sysquery function.

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

- Raw text -