Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAA2zVHoe_Bu2=FApS4YMQ_cgjKJQK4QwTzKLk4z9n1c40u_o1Q@mail.gmail.com>
Date: Thu, 6 Nov 2025 13:03:52 -0500
From: James Y Knight <jyknight@...gle.com>
To: musl@...ts.openwall.com
Cc: Rich Felker <dalias@...c.org>, The 8472 <the8472.rs@...inite-source.de>, 
	Alejandro Colomar <alx@...nel.org>, 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

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.

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.

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.