get size of malloc'd object

[Ben Cranston]

In article <2081 at umcp-cs.UUCP> chris at umcp-cs.UUCP (Chris Torek) writes:

> In article <2206 at peora.UUCP>, jer at peora.UUCP (J. Eric Roskos) writes:
>> ... allocate a sizeof(int) worth of extra space, then store the
>> size of the thing you malloc'ed in the int at the front of the
>> allocated block, advance the pointer past the place where your
>> stored the size, and return that as the pointer to the block you
>> allocated.

> Unfortunately, it is not necessarily portable.  I can imagine a
> machine where `double' arguments must be aligned on an eight-byte
> boundary, but integers are only four bytes wide.  In this case
> calling the new routine to allocate doubles would result in an
> odd-address-style trap when the returned value is used.

I can see three solutions to this problem.  In order of lowest to highest
degree of hacking to Un*x itself:

1. Erect a superstructure upon Malloc that maintains the required additional
   information (this is what Chris did in the deleted part of his posting).
   Requires *no* changes to Un*x, best when the additional gore of the new
   superstructure can be swamped in the gore of a large system within which
   the my-malloc is being distributed (hi Chris!).

2. Require something like malloc.h to include not only the function headers
   for malloc and free, but either one of these two:

#define ALIGNTYPE double
   -or-
#define ALIGNSIZE 8

   The definitions should be obvious.  This requires only the provenance
   of the appropriate header file (and unfortunately standardization of the
   particulars of the implementation... :-).

3. Define the Malloc package portably in C, so the information required can
   be extracted from the underlying data base.  The problem with this
   approach is that the primitives upon which Malloc is based, (e.g. sbrk() )
   would then have to be standardized (hey, maybe this posting belongs in
   this [net.arch] group after all :-).

If anybody is going to do this, and would like to use a Fibonacci number
variant of the binary buddy system, see Rick's and my article in CACM:
"A Simpified Recombination Scheme for the Fibonacci Buddy System", I think
it was either June or July of 1975...

> Of course, malloc() knows all along how big the allocated region
> is (though the number it knows might be larger than the original
> request); so it is a shame to have to go through all this effort.

Yes, but I think there is a question whether you want to tell the user
about 1. how much he ASKED for, or 2. how much happens to BE there...
I think there is an argument for either side, so perhaps there needs to
be two ways of doing this.

Feeping Creaturism???

-- 
                    umd5.UUCP    <= {seismo!umcp-cs,ihnp4!rlgvax}!cvl!umd5!zben
Ben Cranston zben @ umd2.UMD.EDU    Kingdom of Merryland Sperrows 1100/92
                    umd2.BITNET     "via HASP with RSCS"