Does TC's farrealloc have a bug?

[Matthew Smith]

In article <1991Jun19.083945.8921 at ucthpx.uct.ac.za> gram at uctcs.uucp (Graham Wheeler) writes:
>I am reposting this article as I never saw the original appear when using nn
>and have had no responses, so I assume that it got lost.
>
>I have an application in which I am allocating a number of variable sized
>records, of average size about 6 bytes. Whenever the size changes, I use
>farrealloc. I have over 300kb available at the time I start allocating these
>nodes. I also keep track of the number of allocated bytes. My problem is that
>I get a memory allocation failure at about 120kb of allocated memory. This
>must mean one of two things:
>
>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
>Graham Wheeler <gram at cs.uct.ac.za> | "That which is weak conquers the strong,
>Data Network Architectures Lab     | that which is soft conquers the hard.
>Dept. of Computer Science          | All men know this; none practise it"
>University of Cape Town            |		Lao Tzu - Tao Te Ching Ch.78

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.


Matt Smith
msmith at peruvian.utah.edu