From: "G" 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