Message-ID: <3E77500F.7C09422@yahoo.com> Date: Tue, 18 Mar 2003 11:57:51 -0500 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: nmalloc revisited References: <10303181608 DOT AA14409 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 ... > > > > 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. USE worldnet address!