speedy@vax.oxford.ac.uk (06/25/91)
In article <1991Jun20.074613.1279@donau.et.tudelft.nl>, kooijman@duteca.et.tudelft.nl (Richard Kooijman) writes: > msmith%peruvian.utah.edu@cs.utah.edu (Matthew Smith) writes: >>> >>>i) either there is a bug in TC (actually TC++ v1.0) so that when realloc >>> fails to resize a block and allocates a new one it doesn't free the >>> old one; or >>>ii) the allocated blocks are being held on a linked list with an overhead of > >>I've run across a similar situation. I was using realloc as opposed to >>farrealloc, and the same thing happened there. My conclusion after looking >>at several examples in the manuals is that they DON'T delete the old block. > >>This conclusion was achieved by the fact that in all examples, they had a >>dummy pointer pointing to the current block, called realloc with their usual >>pointer, and then called free() with their dummy pointer (which really >>pointed to their old block). That's the way they want you to do it. I know, >>it really sucks. > > I do not understand what you mean with this. In my opinion the problem is > caused by overhead and memory fragmentation. > > The overhead isn't 12 bytes, I think, but 8 bytes as somebody mentioned here > a while ago. > > Richard. I think there is a patch on SIMTEL to correct the bug-it replaces the offending routine in each of the libraries