[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20251107153325.GB1827@brightrain.aerifal.cx>
Date: Fri, 7 Nov 2025 10:33:26 -0500
From: Rich Felker <dalias@...c.org>
To: Michael Winterberg <mike.winterberg@...il.com>
Cc: musl@...ts.openwall.com
Subject: Re: Re: realloci(): A realloc() variant that works in-place
On Thu, Nov 06, 2025 at 03:10:03PM -0800, Michael Winterberg wrote:
> > But, there's no need to rush the growth. It should be fine to wait
> > until you need to grow and then call realloci().
> >
>
> How many extant allocators actually "grow" beyond their result for
> malloc_usable_size?
>
> i.e. if Thiago replaced initial allocations with this,
>
> void* malloc_size_feedback(size_t size, size_t* actual) {
> *actual = 0;
> void* p = malloc(size);
> if (p != 0) {
> *actual = malloc_usable_size(p);
> p = realloc(p, *actual);
> }
> return p;
> }
>
> would there still be a 10% hit rate on reuse?
I can't speak for others, but on musl/mallocng, *actual==size is
guaranteed and the realloc above is a no-op.
If malloc_usable_size(p) returns anything greater than size and the
caller attempts to access past size, compilers *will* see this, note
the UB, and optimize accordingly. This is (among other less critical
reasons) why we make the guarantee.
Rich
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
