[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20251101004808.GR1827@brightrain.aerifal.cx>
Date: Fri, 31 Oct 2025 20:48:08 -0400
From: Rich Felker <dalias@...c.org>
To: Alejandro Colomar <alx@...nel.org>
Cc: Lénárd Szolnoki <cpp@...ardszolnoki.com>,
musl@...ts.openwall.com, libc-alpha@...rceware.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)
On Fri, Oct 31, 2025 at 10:50:52AM +0100, Alejandro Colomar wrote:
> 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).
Um, that would obligate the implementation never to hand out pointers
that happen to be aligned at major boundaries. For example if
0x8000000000000000 ever got allocated, it would be fundamentally
impossible to realloc it.
> 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.
Yes, that's acceptable and can simply be implemented as
aligned_alloc+free.
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.
