[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <lqi2pefiv2st47wx6gg7bw5qx5tlrx5nfbcwumfccbeo7jiet2@o2kszvugwaju>
Date: Fri, 31 Oct 2025 10:50:52 +0100
From: Alejandro Colomar <alx@...nel.org>
To: Lénárd Szolnoki <cpp@...ardszolnoki.com>
Cc: musl@...ts.openwall.com, libc-alpha@...rceware.org,
Rich Felker <dalias@...c.org>, Arthur O'Dwyer <arthur.j.odwyer@...il.com>,
Jonathan Wakely <jwakely@...hat.com>, Thiago Macieira <thiago@...ieira.org>
Subject: Re: alignment guarantees from realloc(3)
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/>).
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.
