Proposed addition of malloc_size_np()

[Jason Evans]

On Mar 27, 2006, at 12:20 PM, John Baldwin wrote:
> On Monday 27 March 2006 11:34, Jason Evans wrote:
>> I can think of a few straightforward uses:
>>
>> 1) Suppose that we are about to write to a string that we know is
>> malloc()ed, and we want to be sure that we aren't overflowing the
>> allocated buffer.  We can add an assertion that the buffer is indeed
>> large enough to contain what is about to be written to it.
>
> In that case though you really want to know the size you allocated,
> not necessarily the backing-store size, esp. if you are in a library
> since your caller may (correctly) assume that if it allocates X
> bytes for a string the library will only write up to X bytes.  So, I
> think in that case you want the requested size, not the backing store
> size.

Yes, you're right that we actually want the requested size rather  
than the backing-store size.  This is only a "better than nothing"  
use case.

>> 4) Porting code from Linux.  Case in point: Xara Xtreme, currently  
>> being
>> ported by Vasil Dimov.  At the moment, he has to use dlmalloc.
>
> Does it contain a G/C of its own or some such?

I don't know the answer to that.

>> Following is what I've written for the malloc(3) man page:
>> ----
>> The malloc_usable_size() function returns the usable size of the
>> allocation pointed to by ptr.  The return value may be larger than  
>> the
>> size that was requested during allocation.  malloc_usable_size()  
>> is not
>> intended as a mechanism for in-place realloc(), though it can be  
>> abused
>> that way; rather it is primarily provided as a tool for introspection
>> purposes.  Any discrepancy between the requested allocation size  
>> and the
>> size reported by malloc_usable_size() should not be depended on,  
>> since
>> such behavior is entirely implementation-dependent.
>> ----
>
> I would word it stronger: "malloc_usable_size() should not be used  
> as a
> mechanism for in-place realloc().  It is provided solely as a tool for
> introspection purposes."

Okay, sounds fine to me.

Thanks,
Jason