Does TC's farrealloc have a bug?#
speedy at vax.oxford.ac.uk
speedy at vax.oxford.ac.uk
Tue Jun 25 22:34:27 AEST 1991
In article <1991Jun20.074613.1279 at donau.et.tudelft.nl>, kooijman at duteca.et.tudelft.nl (Richard Kooijman) writes:
> msmith%peruvian.utah.edu at 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
More information about the Comp.lang.c
mailing list