Hi John,
You wrote to Carey Bloodworth:
JD> CB> you aren't supposed to know how it does it.  (In fact, it can, and
JD> This contrary to every other part of the language.
?????
It is consistant with every other part of the standard library in my
experience. There is _nothing_ anywhere that defines that a standard
library function has to be written in a certain way, just that it has to
take certain parameters, perform a specified operation and return/set
specified results and return/set specified error conditions values.

JD>So, in real terms I would have to
JD>1. know where the &first heapstruct is
JD>2. know the struct layout 14,2,2,10
JD>3. make my own compatable stuct.
JD>4. make a pointer to that kind of stuct.
JD>5. set my pointer to &first.
JD>6. index the pointer to the variable that has allocated the memory.
JD>7. subtract the overhead.
JD>8. return the number of bytes.
The problem is that while many compilers do their own heap allocation
for efficiency there is no reason why a compiler targeted at a system
with an efficient memory allocation mechanism shouldn't make use of it.
JD>My problem would be with #1 and #6.
JD>#1 I would not know how to find the starting address.
JD>#6 I would have no way of knowing which variable was the variable,
JD>   I was looking for.
JD>#2 I could learn from trial and error, maybe documentation.
Only if you know that the compiler library is using a particular method.
JD>CB> There are many ways to do all that.  That's just an example, so you
JD>CB> can't actually use the stuff.  And, as I said, it varies from compiler
JD>CB> to compiler, so you certainly can't portably depend on any internal
JD>CB> information.
JD>I can get ( "great" if something comes of them ) ideas from what you
JD>and others have told me. At the very least I'm learning as I poke
JD>around. Most of what I am learning is solidifying what I should have
JD>known already.
JD>So, unless the compiler maker was nice enough to give me a function
JD>which returns the start address of allocated memory.
JD>and a way of identifying which variable is which, its hopeless.
JD>Unless, I kick over the card table and try another approach.
I still don't see the need in this instance.
JD>The info might be in a book or on the ( in my case, "Borland", 4.5 ) site.
JD>Since this started out to be an error checking routine portablity is not
JD>an issue. In fact since most checking routines, ( I have a large error.c
JD>file I compile with until the final version.), are removed prior to final
JD>compile, portablity is not a restriant.
If you have library source it'll be in there. Otherwise I wouldn't hold
my breath...
George
 * SLMR 2.1a * Wastebasket: Something to throw things near.
--- Maximus/2 3.01
---------------