From:	"G" <msk11 AT cornell DOT edu>
Newsgroups:	comp.os.msdos.djgpp
Subject:	Possible Bug in realloc()
Date:	Mon, 16 Aug 1999 20:05:41 -0400
Organization:	Cornell University
Lines:	45
Sender:	msk11 AT cornell DOT edu (Verified)
Message-ID:	<7pa8ti$73k@newsstand.cit.cornell.edu>
NNTP-Posting-Host:	98cbbec0.ipt.aol.com
X-Priority:	3
X-MSMail-Priority:	Normal
X-Newsreader:	Microsoft Outlook Express 5.00.2314.1300
X-MimeOLE:	Produced By Microsoft MimeOLE V5.00.2314.1300
To:	djgpp AT delorie DOT com
DJ-Gateway:	from newsgroup comp.os.msdos.djgpp
Reply-To:	djgpp AT delorie DOT com

Hi there,
   I've been using DJGPP for a couple of months now and am very impressed by
it. Thanks to all of you who put forth all of the effort necessary to create
it! I think that I may have come across a bug, however. When I was looking
through the source code for realloc() I found the following lines in the
code for realloc() :
newptr= (char *)malloc(size);
.
.
.
memcpy(newptr, ptr, copysize);
free(ptr);
return newptr;

   It appears to me that when malloc is unable to allocate the requested
amount of memory and returns NULL, data from the old block of memory(whose
address is ptr) is copied to offset 0. I stepped through the code with RHIDE
and this is what appears to happen. I'm pretty sure this is not what was
intended. Of course, this is easy to fix by checking the newptr!=0 before
the copy. Please let me know if I have made a mistake here.
   Also, while on the subject, may I suggest a new function similar to
realloc() that also changes the size of a memory block and copies data if
necessary, but one the keeps the old block of memory reserved if it cannot
allocate a larger block. This would be very useful for times when one is
building a growing set of data and doesn't want to lose it all when it can't
be made any larger. I have thought of writing a function that does this
using exising memory allocation functions such as malloc() but the problem
with this approach is illustrated by the following example:
   Let's say you have 600 total units of space on the computer.
   Say 300 units are allocated in 1 large block and the subsequent 300 are
free.
   If you want to enlarge the first block to 500 units, a "smart" realloc()
could just enlarge the 300 unit block to 500 units if no block were already
using the 200 units of space immediately following the 300 unit block.
Malloc(), on the other hand would only see 300 free units(not knowing the
300 units already used could be part of the necessary 500) and so would deny
the request for a 500 unit block whereas a "smart" reallloc could grant it.
Unfortunately I don't know enogh of the internals of DJGPP memory blocks to
write such a function, but if anyone has such a function I would love to
know about it.
   Thanks for your time, I hope I have been of some help.
G. Kashan
kashan AT aecom DOT yu DOT edu

- Raw text -