Message-ID: <3A6E9FDD.C51D05E5@acm.org> From: Eric Sosman 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: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit 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