Proposed addition of malloc_size_np()

[John-Mark Gurney]

Jason Evans wrote this message on Mon, Mar 27, 2006 at 08:34 -0800:
> John Baldwin wrote:
> >On Sunday 26 March 2006 13:04, Jason Evans wrote:
> >
> >>Robert Watson wrote:
> >>
> >>>I wonder if the intuitive objection people are raising is actually with 
> >>>the name.  Since malloc_size() is defined on at least one platform to 
> >>>return the requested size, maybe a name like malloc_allocated_size() (or 
> >>>something a bit more compact) would help avoid that confusion, and make 
> >>>it clear that the consumer is getting back a commitment and not a hint 
> >>>for future realloc(), etc.
> >>
> >>Maybe you're right.  We could just call it malloc_usable_size() and be 
> >>compatible with Linux.
> >
> >It would help to know why such a function would be useful. :)  Do you have
> >a specific use-case?  If the purpose is for a program to see that it really
> >as Y >= X bytes when it did malloc(X) so that the program can use Y bytes,
> >that would seem to only be a source of bugs and complexity.  If the program
> >wants Y bytes, it should malloc(Y).  Many folks in the thread seem to think
> >that this function would be used for a poor-man's realloc() wrapper or
> >something, and I think such uses would be short-sighted at best.  If there
> >are other uses such as for having a debug malloc wrap the real one, then
> >that might justify the API, but it is unclear what a useful use of this API
> >would be.
> 
> I can think of a few straightforward uses:

[...]

> 2) Suppose that we are using some sort of dynamically scalable data 
> structure, such as a hash table that we double in size every time 
> fullness crosses some threshold.  In order to do that, we need to know 
> how large the table is.  We can store that information, or we could just 
> query the size.  (In this example, performance constraints might dictate 
> that we actually store the size of the table, but there are certainly 
> similar examples that wouldn't be so concerned with performance.)

This use case is incorrect...  a) you already have the size, since you
have your hashing value around..  and b) you could end up with part of
your has table uninitalized, say, alloc and initalize 24 bytes, the
function returns 32, so you think, oh, well, bytes 25 through 32 are
initalized, so I don't have to do anything..  This use case is correct
if you used it as a poor man's realloc, where you allocated a block,
then asked the size, but then, you may very well end up with a very bad
hash value..  and in this case, you might as well realloc to this side..

> 4) Porting code from Linux.  Case in point: Xara Xtreme, currently being 
> ported by Vasil Dimov.  At the moment, he has to use dlmalloc.

sad to say, but we seem to always inherit Linux's warts in the name of
portability.. :(  I'd say adopt a method similar to the ports tree, once
we have 10+ ports depending upon it, then we can consider this.. but
importing this function for a single program seems a bit excessive..

-- 
  John-Mark Gurney				Voice: +1 415 225 5579

     "All that I will do, has been done, All that I have, has not."