Message-ID: <3DEDAA53.AD9F32A4@yahoo.com> Date: Wed, 04 Dec 2002 02:10:11 -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: malloc()s References: <10211302010 DOT AA15154 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: > > > In src/libc/ansi/stdlib/ there is bsdmallo.c which looks like > > some old malloc implementation which isn't used. > > > > Should it be removed? > > No. Different mallocs have different strengths and weaknesses. > > > Or should we add CBFalconer's malloc as cbfmallo.c. > > This might be a way to store the code until we get it upgraded ... > > Eventually it should be malloc.c with the current one being > djmalloc.c, but we're not ready yet > > > If we just add them with new names we have the nice ability to > > switch which one we want by changing one line in the makefile. > > Or someday allow multiple mallocs just by a different -lbsdmalloc, > or -ldjmalloc what weakness? I have yet to hear a single criticism from anyone. AFAICT the makefile will generate an object file ready to drop into the library (depends on defining NDEBUG), and everything works (that is dependent on standards). The overhead goes up to 24 bytes per allocation from the present 16. There is much less data movement on realloc, so much more likely to return the same pointer, and free is always an O(1) operation - never any searches for adjacencies. I have no objection to calling it cbfmallo rather than nmalloc. :-) -- Chuck F (cbfalconer AT yahoo DOT com) (cbfalconer AT worldnet DOT att DOT net) Available for consulting/temporary embedded and systems. USE worldnet address!