Proposed addition of malloc_size_np()

[Andrew Reilly]

On Mon, Mar 27, 2006 at 12:52:17PM -0800, Jason Evans wrote:
> [1] In a slightly more ideal world, we would add malloc_size()  
> instead of malloc_usable_size(), which would return the size that was  
> passed to malloc()/calloc()/realloc().  However, that would impose  
> implementation constraints on the allocator that would have far- 
> reaching implications.

You could do this in your malloc wrapper, if you wanted: just
have it maintain a (growable) hash table of sizes, keyed by
allocation address.  You'd return the real (asked-for) size as
the malloc_useable_size(), but any client code of that function
would have to behave sensibly in any case: it can't know that it
isn't running against something like a traditional first-fit
allocator or the like that doesn't round up.

> I don't want to get into the details here,  
> but suffice it to say that requiring support for malloc_size() would  
> require a lot of extra space overhead for many allocator designs,  
> including for phkmalloc and jemalloc.

I've just written my own allocator for an embedded project
(extra constraints are often better served by changing API,
imo.)  Anyway, it's very simple, and malloc_useable_size would
be quite slow; malloc_size would be impossible without something
extra, like the hash-table that I mentioned.

Incidentally, what should malloc_useable_size() do if passed a
pointer that wasn't [cmr]alloc()'d?  The same sort of
warning/trap as free()?

-- 
Andrew