Date: Wed, 24 Jan 2001 18:27:36 +0200
From: "Eli Zaretskii" <eliz AT is DOT elta DOT co DOT il>
Sender: halo1 AT zahav DOT net DOT il
To: Eric Sosman <esosman AT acm DOT org>
Message-Id: <3405-Wed24Jan2001182735+0200-eliz@is.elta.co.il>
X-Mailer: Emacs 20.6 (via feedmail 8.3.emacs20_6 I) and Blat ver 1.8.6
CC: djgpp AT delorie DOT com
In-reply-to: <3A6E9FDD.C51D05E5@acm.org> (message from Eric Sosman on Wed, 24
	Jan 2001 14:25:33 GMT)
Subject: Re: Advance warning of failure of realloc()
References: <Pine DOT SUN DOT 3 DOT 91 DOT 1010124100451 DOT 25819A AT is> <3A6E9FDD DOT C51D05E5 AT acm DOT org>
Reply-To: djgpp AT delorie DOT com
Errors-To: nobody AT delorie DOT com
X-Mailing-List: djgpp AT delorie DOT com
X-Unsubscribes-To: listserv AT delorie DOT com
Precedence: bulk

> From: Eric Sosman <esosman AT acm DOT org>
> Newsgroups: comp.os.msdos.djgpp
> Date: Wed, 24 Jan 2001 14:25:33 GMT
> > 
> > DJGPP's implementation supports this feature, but please note that it
> > comes for a price: if you are enlarging the buffer `realloc' allocates
> > a new buffer before it frees the old one.  So it can report a failure
> > even though the remaining amount of memory is large enough to hold the
> > enlarged buffer.
> 
>     The supposition for realloc() is that the content of the
> existing block is valuable and cannot be discarded.  That being
> the case, it's difficult to see how the situation you describe
> could arise unnecessarily.

Suppose you have a buffer whose size is 2KB, and suppose you asked
`realloc' to enlarge it to 4KB.  Suppose, further, that you only have
3KB of free memory left.  Since `realloc' tries to allocate 4KB before
copying the data and freeing the old buffer, `realloc' will fail even
though you have enough memory (2KB + 3KB = 5KB) to satisfy the call.

While nobody will miss a mere 1KB, imagine the same example where you
wanted to enlarge a 2MB buffer to 4MB.  A whole 1MB of memory somehow
becoming unavailable will certainly be noticed!

This was the situation I was referring to.  This is the price users
need to be aware of when they write memory-intensive applications.

As for how this could be done differently--`realloc' could check if
there's enough free memory immediately following the old block, for
example, or maybe defragment some smaller blocks immediately before
and after the old one.  DJGPP's implementation doesn't do that.