Message-ID:	<3DB642F4.AAED778D@yahoo.com>
Date:	Wed, 23 Oct 2002 02:34:28 -0400
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: CBFalconer's malloc
References:	<10210230425 DOT AA17374 AT clio DOT rice DOT edu>
Reply-To:	djgpp-workers AT delorie DOT com

Charles Sandmann wrote:
> 
... snip ...
> 
> There is no on-line help or detailed examples such as malldbg has;
> so the how to is less clear.  It needs to be something packaged
> into a final product.
> 
> I would also suggest _sysquery isn't clear; maybe _malloc_query
> or something would be better if retained.

Fine.  That doesn't affect the fundamental soundness (or lack
thereof) of nmalloc.  I simply proposed a clean method of
interfacing future debuggery which does not require detailed
unclean knowledge of the package interior.

> 
> (Note the current malloc() free is still broken, so we have to do
> something, I'm just not sure what.  And I'm on a 19.2K modem with
> 200ms latency, so I'm lucky to read email for the next 2 weeks).
> My emergency fix is to stop looking for free merges after a short
> search.

I have simply compiled the appropriate form of nmalloc (see the
makefile) to generate malloc.o, which I can then link ahead of the
library.  The problem is gone.  As far as I can tell it should be
possible to move that module into the binary library and stop
worrying about it.  Of course the present debuggery hacks would
not work since the structure (and overhead) is different.

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