Mail Archives: djgpp/2001/01/24/11:35:09
> 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.
- Raw text -