delorie.com/archives/browse.cgi   search  
Mail Archives: djgpp/1997/01/28/04:13:37

Date: Tue, 28 Jan 1997 11:08:49 +0200 (IST)
From: Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
To: "A.Appleyard" <A DOT APPLEYARD AT fs2 DOT mt DOT umist DOT ac DOT uk>
cc: DJGPP AT delorie DOT com
Subject: Re: A misfeature re malloc() and new
In-Reply-To: <957C9527FA@fs2.mt.umist.ac.uk>
Message-ID: <Pine.SUN.3.91.970128110407.10987B-100000@is>
MIME-Version: 1.0

On Mon, 27 Jan 1997, A.Appleyard wrote:

> n+4 and p+4 are in the same interval between successive powers of 2. That
> means that if a program once needs to malloc() a very big block (say a
> megabyte), and then to free() it, the store allegedly freed is not really free
> for reallocation to later small malloc() calls, but is dead space.

Can you post a short program that exhibits this behavior?  I had on a few
occasions thought I've found a severe bug in that algorithm, but malloc
surprised me when I tried to write a program that would fail it. 

> What workrounds exist for this problem?

If the problem is indeed a real one, nothing short of replacing the malloc
algorithms would do, IMHO.  If you don't care about GPL restrictions, you
can download the GNU Malloc library and use it instead (the Emacs source
distribution includes it, and Emacs uses those functions instead of those
from libc). 

- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019