X-Sybari-Trust: 29c62d18 ca231590 9763731a 00000138 From: Martin Stromberg Message-Id: <200212040946.KAA17407@lws256.lu.erisoft.se> Subject: Re: 2.04 CVS Build plan To: djgpp-workers AT delorie DOT com Date: Wed, 4 Dec 2002 10:46:11 +0100 (MET) In-Reply-To: <3DEDB313.9627F062@yahoo.com> from "CBFalconer" at Dec 04, 2002 02:47:31 AM X-Mailer: ELM [version 2.5 PL3] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Reply-To: djgpp-workers AT delorie DOT com Errors-To: nobody AT delorie DOT com X-Mailing-List: djgpp-workers AT delorie DOT com X-Unsubscribes-To: listserv AT delorie DOT com Precedence: bulk CBFalconer said: > *** Posted and mailed *** I'd appreciate if you didn't mail me when mailing djgpp-workers. > Martin Stromberg wrote: > > > > > 1) Resolve the malloc() issue > > > > > We either need to modify our free algorithm with an early out to > > > stop merging blocks if the free list is long, or convert to the > > > new contributed code. We could do a test build with the new > > > malloc() hand inserted to see if most things behave properly. > > > > I did this, if building libc and the accompanying tools counts. > > > > > to tweak interfaces or change documentation. Given the time limits > > > > This hasn't had any progress. I'm waiting for the original author > > (CBFalconer) (or somebody else) to correct these issues. > > What issues? AFAICT compiling the original source with NDEBUG > results in a module ready for inclusion in the main library. I > added the following readme to the distribution, not sure just now > if it is in the version on my site. The nmalloc code has not been > altered. The issue (AFAICT) seems to be that it doesn't integrate with the existing malloc debuggery already present in libc. As it breaks what is already there, it doubt it will be used. I could of course be wrong. Right, MartinS