Date: Tue, 28 Mar 2006 20:11:53 +1100 From: Peter Jeremy <peterjeremy@optushome.com.au> To: Jason Evans <jasone@freebsd.org> Cc: freebsd-arch@freebsd.org Subject: Re: Proposed addition of malloc_size_np() Message-ID: <20060328091153.GC961@turion.vk2pj.dyndns.org> In-Reply-To: <352D1430-CC72-47EE-9E50-B1C4404ACA95@FreeBSD.org> References: <44247DF1.8000002@FreeBSD.org> <20060326110929.V35431@fledge.watson.org> <4426D7A0.4040007@FreeBSD.org> <200603271110.02917.jhb@freebsd.org> <44281421.3060401@FreeBSD.org> <20060327185017.GF7001@funkthat.com> <352D1430-CC72-47EE-9E50-B1C4404ACA95@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 2006-Mar-27 12:52:17 -0800, Jason Evans wrote: >void * >malloc(size_t size); > >void * >calloc(size_t size); > >void * >realloc(void *ptr, size_t size, size_t old_size); > >void >free(void *ptr, size_t size); ISTR AmigaDOS did something like this (my autodocs are packed away somewhere so I can't quickly check). The downside is that you have to keep the malloc() size stashed away so you can pass it to free(). This could be problematic where a function returns malloc'd memory (eg asprintf(), strdup()). It also fails to solve the leak from: ptr = realloc(ptr, NEW_SIZE); where realloc() returns NULL. In an ideal world, a pointer would be an [address, size] pair (or even [size, address, type] tuple) so that any the bounds (and type) can be verified by anything that wants to. (The iAPX432 tried this). I think we've got even less chance of re-designing C than re-designing malloc (and C++ can't do this because you can't override builtin types). >breaking compatibility. Let's re-visit Poul-Henning's suggestion, >which involves a parallel API that exposes the internal sizes to the >application. The following is not identical to what he proposed, but >it has the same semantics: > >void * >malloc_np(size_t *size); > >void * >calloc_np(size_t *size); > >void * >realloc_np(void *ptr, size_t *size, size_t *old_size); > >void * >memalign_np(size_t alignment, size_t *size); > >void * >free_np(void *ptr, size_t *size); A try_realloc() function would be nice - where you can determine whether the realloc succeeded or not (or maybe how much memory it could obtain) without accidently leaking the old region if the realloc() failed. >[1] In a slightly more ideal world, we would add malloc_size() >instead of malloc_usable_size(), which would return the size that was >passed to malloc()/calloc()/realloc(). However, that would impose >implementation constraints on the allocator that would have far- >reaching implications. I don't want to get into the details here, >but suffice it to say that requiring support for malloc_size() would >require a lot of extra space overhead for many allocator designs, >including for phkmalloc and jemalloc. If you really want to detect off-by-one errors, realloc() and free() need to know exactly how many bytes were asked for so they can verify that the immediately following byte still has the magic value that malloc/realloc wrote there. (Admittedly, this is for debugging only). -- Peter Jeremy
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20060328091153.GC961>