Message-ID:	<3A6E9FDD.C51D05E5@acm.org>
From:	Eric Sosman <esosman AT acm DOT org>
X-Mailer:	Mozilla 4.72 [en] (Win95; U)
X-Accept-Language:	en
MIME-Version:	1.0
Newsgroups:	comp.os.msdos.djgpp
Subject:	Re: Advance warning of failure of realloc()
References:	<Pine DOT SUN DOT 3 DOT 91 DOT 1010124100451 DOT 25819A AT is>
Lines:	25
Date:	Wed, 24 Jan 2001 14:25:33 GMT
NNTP-Posting-Host:	12.78.205.247
X-Complaints-To:	abuse AT worldnet DOT att DOT net
X-Trace:	bgtnsc06-news.ops.worldnet.att.net 980346333 12.78.205.247 (Wed, 24 Jan 2001 14:25:33 GMT)
NNTP-Posting-Date:	Wed, 24 Jan 2001 14:25:33 GMT
Organization:	AT&T Worldnet
To:	djgpp AT delorie DOT com
DJ-Gateway:	from newsgroup comp.os.msdos.djgpp
Reply-To:	djgpp AT delorie DOT com

Eli Zaretskii wrote:
> 
> On Tue, 23 Jan 2001, Jack Klein wrote:
> 
> > I don't have source to DJGPP realloc() handy at the moment, but I
> > would be surprised if it did not follow the standard.
> 
> 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.

    If the existing contents are *not* valuable, of course, you
could simply use free() followed by malloc() instead of using
realloc() in the first place.

-- 
Eric Sosman
esosman AT acm DOT org

- Raw text -