Date: Sun, 26 Mar 2006 11:11:18 +0000 (GMT) From: Robert Watson <rwatson@FreeBSD.org> To: Jason Evans <jasone@FreeBSD.org> Cc: John-Mark Gurney <gurney_j@resnet.uoregon.edu>, freebsd-arch@FreeBSD.org Subject: Re: Proposed addition of malloc_size_np() Message-ID: <20060326110929.V35431@fledge.watson.org> In-Reply-To: <442595E2.5080804@FreeBSD.org> References: <44247DF1.8000002@FreeBSD.org> <200603250806.k2P86YJU011861@apollo.backplane.com> <4424FDE9.3080707@FreeBSD.org> <20060325185612.GC7001@funkthat.com> <442595E2.5080804@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, 25 Mar 2006, Jason Evans wrote: >> Ok, so what you are saying is that the function returns the size of the >> bucket (if any) that the memory was allocated from... But even though this >> function may return a larger value, the program is not allowed to use extra >> space, and it's only useful for further allocations of the same size? > > I'm saying that malloc_size_np() returns the size of the allocation, to the > best of the allocator's knowledge. If you malloc(17), and malloc_size_np() > returns 32 for that allocation, then you can treat it as a 32-byte > allocation. However, the malloc implementation could conceivably return any > value >=17. 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. Robert N M Watson
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20060326110929.V35431>