[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20251031060017.GQ1827@brightrain.aerifal.cx>
Date: Fri, 31 Oct 2025 02:00:17 -0400
From: Rich Felker <dalias@...c.org>
To: Alejandro Colomar <alx@...nel.org>
Cc: libc-alpha@...rceware.org, musl@...ts.openwall.com,
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 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.
>
> 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.
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.
