Does TC's farrealloc have a bug?

[Graham Wheeler]

In <6574 at ns-mx.uiowa.edu> colburn at tessa (alex colburn) writes:

>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
>>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

>	I don't think your problem lies in Borland's internal memory
>management systems, it would kind of silly for them to write something
>that uses twice as much memory as it is managing.  Is this error message
>something you get, and then its time for a reboot?  If so, I bet you're
>referencing invalid addresses.

No, I print the error message when farrealloc returns NULL, and I do a clean
exit.
>   	How are you keeping track of your reallocated memory?  If you have
>some sort of linked list data structure, when you farrealloc you just might
>be scrambling pointers.  For debugging purposes try doing a farheapcheck()

I actually have a tree structure (in fact, a graph) but instead of using
pointers I use indexes into an array of pointers. This means I don't have to
go patch all references to a node whose address might get changed by	
realloc.

The problem is not a bug in the structure (it works fine); just that I am
running out of memory too soon. And from the responses I have seen, this seems
to be due to the 16-byte granularity of allocations, bearing in mind my
average allocation is for six bytes.
--
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