Proposed addition of malloc_size_np()
Julian Elischer
julian at elischer.org
Mon Mar 27 17:49:05 UTC 2006
Jason Evans wrote:
> 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:
>
> 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.
Iff it retunrs a numbre greater than teh alocated size, then
this is a programmer error.. he should have malloc'd a bigger buffer.
On the other hand malloc_allocated_size (which returns the allocated
size) might be usefull if
a library which is given a buffer wants to know how much room there is
in a buffer.
Of course there is nothing saying that we gave the library a pointer to
the BEGINNING of the buffer
so it should report "distance from the pointer to the end". Doesn't work
for strings off the stack (alloca())
or static, etc
>
> 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.)
As you say.. just store it... though a library wouldn't have access to that.
>
> 3) This is what I want malloc_usable_size() for: garbage collection.
> In order for a garbage collector to know when it should run, there
> needs to be some way of tracking how much memory is in use. By using
> dlsym(RTLD_NEXT, ...), I can intercept all malloc/calloc/realloc/free
> calls and track current memory usage. However, unless there is a way
> of getting the size of each allocation, I don't know how much to
> subtract from the count for realloc/free calls.
>
> 4) Porting code from Linux. Case in point: Xara Xtreme, currently
> being ported by Vasil Dimov. At the moment, he has to use dlmalloc.
>
> Jason
>
> 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.
> ----
> _______________________________________________
> freebsd-arch at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-arch
> To unsubscribe, send any mail to "freebsd-arch-unsubscribe at freebsd.org"
More information about the freebsd-arch
mailing list