Message-ID: <3DB642F4.AAED778D@yahoo.com> Date: Wed, 23 Oct 2002 02:34:28 -0400 From: CBFalconer 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> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit 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. USE worldnet address!