[musl] alignment guarantees from realloc(3)

Alejandro Colomar alx@kernel.org
Fri Oct 31 09:50:52 GMT 2025


Hi Lénárd, Rich,

On Fri, Oct 31, 2025 at 06:58:19AM +0000, Lénárd Szolnoki wrote:
> 
> 
> On 31/10/2025 06:00, Rich Felker wrote:
> > On Fri, Oct 31, 2025 at 12:29:25AM +0100, Alejandro Colomar wrote:
> > > Hi!
> > > 
> > > 
> > > A discussion in the C++ std-proposals@ mailing list triggered a
> > > discussion about the lack of aligned_realloc().
> > > 
> > > I don't think we want an aligned_realloc(), as it would be very weird to
> > > change the alignment of a block of memory.  Once you have there some
> > > contents, the alignment would just have to be preserved.
> 
> (sorry, replying here, I don't have Alejandro's email directly for some reason)
> 
> That's not my impression of what the semantics of aligned_realloc should be.
> Indeed, it shouldn't be able to realloc to a differently aligned buffer, it
> should be undefined if the user provides an alignment that does not match
> the alignment the original buffer was allocated with.
> 
> This puts the responsibility to the user to preserve the alignment
> information of the allocated buffer if they wish to do so, without needing
> to change existing allocator implementations to store the alignment of each
> allocation.

That would be an option.

> > > Thus, I think realloc(3) should preserve the alignment from a previous
> > > aligned_alloc(3), and thus, not need an aligned_realloc() at all.
> > > 
> > > Before writing a proposal for the standards, I'd like to ask about the
> > > feasibility of adding this guarantee in realloc(3) in glibc and musl.
> > > Would you mind adding such a guarantee to realloc(3)?
> > > 
> > > The precise wording I'm considering for a standards proposal will look
> > > something like this:
> > > 
> > > 	realloc(3) shall preserve the alignment of a block allocated
> > > 	previously by aligned_alloc(3).
> > 
> > I don't see this as feasible at all. It's a new requirement to store
> > the original requested alignment with each allocation, which can be a
> > significant storage burden, and has only niche applications at best.

How about just checking the alignment of a block of memory, and aligning
the new one with at least the same alignment?  You wouldn't need to
store the requested alignment.  A drawback would be overalignment (and
thus, unnecessary failures).

Alternatively, an aligned_realloc() where the user is responsible for
passing the same exact alignment every time --as Lénárd said-- would
make sense.

> > 
> > Rich

Have a lovely day!
Alex

-- 
<https://www.alejandro-colomar.es>
Use port 80 (that is, <...:80/>).
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <https://sourceware.org/pipermail/libc-alpha/attachments/20251031/3ba3dc20/attachment.sig>


More information about the Libc-alpha mailing list