Date: Sat, 25 Mar 2006 09:37:29 +0100 From: Maxime Henrion <mux@FreeBSD.org> To: Jason Evans <jasone@FreeBSD.org> Cc: freebsd-arch@FreeBSD.org Subject: Re: Proposed addition of malloc_size_np() Message-ID: <20060325083729.GN80618@elvis.mu.org> In-Reply-To: <44247DF1.8000002@FreeBSD.org> References: <44247DF1.8000002@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20060325083729.GN80618>