> DN> Not by any documented means. The RTL or at least the
 > DN> operating system almost certainly would need to track the
 > DN> existing size of allocated memory blocks in order to
 > DN> implement realloc(), but the C programmer has no direct
 > DN> access to that information. It is ultimately up to you to
 > DN> keep track of it yourself.

 > Yep, someone will just have to find that location/table or whatever :)
 > There must be a table somewhere holding a handle,address and bytes.

Actually, it is normally stored at the start of the block, which also
contains linked list information. But that need not be the case. What you
get working with one compiler certainly won't work with another, so the
work would be pretty much a waste of time anyway.

OTOH, you could just implement your own low-level malloc() and have control
over it. I did that once, although it wasn't a C standard malloc, but a
"pointer-to-pointer" strategy that used logical memory handles
rather than pointers to the blocks themselves. This (I found out later :-))
is similar to how Windows used to operate in real mode. It had the
advantage of allowing memory block compaction, so it eliminated the problem
of memory fragmentation completely. When you freed memory, anything
"above" that block would be moved down. You also had to
"lock" a block of memory (in which free would just add a pointer
to free to a table), then "unlock" it afterwards, at which point
the free's in between would all take effect.

But in any case, memory size information was /still/ not available to the
programmer. The principle of encapsulation applies. The bottom line is that
if you want to track memory block sizes explicitly, then do it explicitly.
Don't rely on compiler and/or operating system specific information,
particularly if what you're doing isn't documented.


 > Thanks, this'll ruin a whole afternoon for me to work out :)

You shouldn't find it too difficult. When allocating > 0 bytes it just
adds information to the start of the block that contains the size and a
"magic number" that attempts to be a reasonably reliable way of
ensuring that it is not a wild pointer to somewhere weird.


 > That imaginary memtable still bugs me though, if it's in there i want it.

It may not be there at all. Pretend it is "invisible", since it
is, in essence. As I said, if you get it working on one compiler, then it
assuredly won't work with any other.

--- MaltEd/2 1.0.b6