Re: Proposed addition of malloc_size_np()

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
_______________________________________________
freebsd-arch@xxxxxxxxxxx mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "freebsd-arch-unsubscribe@xxxxxxxxxxx"

Relevant Pages