Proposed addition of malloc_size_np()
Maxime Henrion
mux at FreeBSD.org
Sat Mar 25 08:37:33 UTC 2006
Jason Evans wrote:
> === Proposal ===
> Add malloc_size_np() to libc, and provide the prototype in malloc_np.h:
>
> size_t
> malloc_size_np(const void *ptr);
>
> This function would return the usable size of the allocation pointed to
> by ptr, which is always greater than or equal to the size that was
> specified in the call to malloc(), calloc(), posix_memalign(), or
> realloc(), regardless of allocator implementation. It is up to the
> implementation whether the value returned by malloc_size_np() differs
> from the size specified during allocation, but the return value must be
> consistent across multiple calls for the same allocation.
>
> === Rationale ===
> The standard malloc(3) API does not provide a mechanism for querying the
> sizes of existing allocations. This can be useful for a variety of
> purposes, including introspection and putting wrappers around the system
> malloc implementation. For a stand-alone application, it is possible to
> always keep track of allocation sizes, but when integrating with third
> party libraries, this may not be possible.
>
> The lack of such a function causes issues when porting software from
> Linux or OS X. Linux provides malloc_usable_size(), which returns the
> usable size of an allocation (may be larger than the allocation request
> size). OS X provides malloc_size() and malloc_good_size(), which return
> the precise allocation request size and the usable size of the
> allocation, respectively. By providing malloc_size_np(), we provide an
> analogue to these APIs, without placing undue constraints on future
> malloc implementations.
>
> I propose malloc_size_np() rather than malloc_size() (and a separate
> header file) in order to emphasize the non-portability of this function.
> As a case in point, the proposed semantics differ from those of OS X's
> malloc_size(). If we were to use malloc_size(), there would be the
> potential for undue expectation of equivalence between operating systems.
>
> ===
I like this idea and, for one, can't see anything to change in your
proposal :-).
Cheers,
MAxime
More information about the freebsd-arch
mailing list