Xref: utzoo comp.lang.c:40455 comp.os.msdos.programmer:5927
Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!wuarchive!uunet!mcsun!ukc!ox-prg!oxuniv!speedy
From: speedy@vax.oxford.ac.uk
Newsgroups: comp.lang.c,comp.os.msdos.programmer
Subject: Re: Does TC's farrealloc have a bug?#
Message-ID: <1991Jun25.133427.825@vax.oxford.ac.uk>
Date: 25 Jun 91 12:34:27 GMT
References: <1991Jun19.083945.8921@ucthpx.uct.ac.za> <1991Jun19.131158.5335@hellgate.utah.edu> <1991Jun20.074613.1279@donau.et.tudelft.nl>
Organization: Oxford University Computing Service
Lines: 29

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