[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <jt3uyqxtvhkoeuj46myq5ml6xkdzj5ima6ef7lj6jcs73ena5m@b37utxk3jnr7>
Date: Thu, 6 Nov 2025 22:49:38 +0100
From: Alejandro Colomar <alx@...nel.org>
To: James Y Knight <jyknight@...gle.com>
Cc: musl@...ts.openwall.com, Rich Felker <dalias@...c.org>,
The 8472 <the8472.rs@...inite-source.de>, Thiago Macieira <thiago@...ieira.org>,
Florian Weimer <fw@...eb.enyo.de>, libc-alpha@...rceware.org,
Arthur O'Dwyer <arthur.j.odwyer@...il.com>, Jonathan Wakely <jwakely@...hat.com>
Subject: Re: Re: realloci(): A realloc() variant that works in-place
Hi James,
On Thu, Nov 06, 2025 at 01:03:52PM -0500, James Y Knight wrote:
> On Tue, Nov 4, 2025 at 7:38 PM Demi Marie Obenour <demiobenour@...il.com> wrote:
> >
> > Would it be better to provide an allocation API that returns the amount
> > of memory actually allocated? That would at least allow any padding at
> > the end of the allocation to be used instead of being wasted.
>
> Yes, a new malloc variant with direct size feedback would be a much
> better idea than a new non-moving realloc variant. And, for people who
> care about usefulness for C++: that's already the direction C++
> started to go.
I disagree. Most users don't need this, and should use this.
malloc(3) is already a special case of realloc(3), but it's useful
enough that it warrants a separate function.
However, for the case of realloci(), I don't see the usefulness of a
hypothetical malloci() to be enough to justify it.
After all, you can do this:
p = malloc(size);
if (p == NULL)
goto fail;
actual_size = realloci(p, size);
And the realloci() call should be cheap compared to malloc(3). There's
absolutely no need to conflate this into a new function. realloci()
should be enough.
If you'll do that often enough, feel free to wrap it yourself:
void *
malloci(size_t *size)
{
ssize_t s;
void *p;
p = malloc(*size);
if (p == NULL)
return NULL;
s = realloci(*size);
if (s != -1)
*size = s;
return p;
}
But, there's no need to rush the growth. It should be fine to wait
until you need to grow and then call realloci().
> Crucially, the new function must return both the pointer and the
> newly-allocated-size (which must be at least the requested size but
> could be more). Because this is a new API, it is explicitly opt-in for
> callers who know they _want_ to be able to grow into the remainder of
> an implementations rounded-up allocation-bucket size, and therefore
> would not trigger UB concerns or reduce the ability to detect
> overflows from "normal" fixed-size allocations done with malloc.
>
> This has been covered before in C++ standards proposals:
> https://wg21.link/p0401 is already in C++23. It adds an API
> `std::allocation_result<T*, std::size_t> allocate_at_least(std::size_t
> n);" to the allocator template interface. libcxx defines this, and its
> standard-library containers e.g. vector call it.
>
> Unfortunately, the default allocate_at_least currently only ever
> returns the exact requested-size, because there's currently no
> standard allocation API to request size-feedback from the default
> system allocator. But, if you provide a user-defined allocator
> template argument to the container (e.g. via "std::vector<int,
> MyCustomAllocator>"), you can use this functionality today.
>
> To address the desire to have it by default, there is a second
> proposal: https://wg21.link/p0901, which proposes to add a new
> "operator new" overload (again, takes a requested size, returns
> pointer and actually-allocated size), that the default
> "allocate_at_least" should call. Unfortunately, that is NOT in C++
> yet. (I believe the last action was that there was mostly support for
> the feature but the proposal needed some tweaks).
>
> It would be useful to have a C API for this if P0901 ends up in the
> C++ spec, because the default C++ standard library "operator new"
> implementations typically just call libc malloc.
I don't see this being used in C, so I think the C implementation should
be just enough to allow C++ to do their thing. For that, realloci()
would be enough. C++ can call it immediately after malloc(3) if needed,
and can wrap it with the malloci() from above if they want.
Have a lovely night!
Alex
--
<https://www.alejandro-colomar.es>
Use port 80 (that is, <...:80/>).
Download attachment "signature.asc" of type "application/pgp-signature" (834 bytes)
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.
