Xref: utzoo comp.lang.c:40256 comp.os.msdos.programmer:5744
Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!samsung!olivea!tardis!tymix!uunet!mcsun!hp4nl!donau!duteca.et.tudelft.nl!kooijman
From: kooijman@duteca.et.tudelft.nl (Richard Kooijman)
Newsgroups: comp.lang.c,comp.os.msdos.programmer
Subject: Re: Does TC's farrealloc have a bug?
Keywords: farrealloc,realloc,memory
Message-ID: <1991Jun20.074613.1279@donau.et.tudelft.nl>
Date: 20 Jun 91 07:46:13 GMT
References: <1991Jun19.083945.8921@ucthpx.uct.ac.za> <1991Jun19.131158.5335@hellgate.utah.edu>
Sender: news@donau.et.tudelft.nl (UseNet News System)
Organization: Delft University of Technology, Dep. of Electrical engineering
Lines: 24
Nntp-Posting-Host: duteca.et.tudelft.nl

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.