[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ba15f424-02ce-4866-b681-531718cb4e54@lenardszolnoki.com>
Date: Fri, 31 Oct 2025 06:58:19 +0000
From: Lénárd Szolnoki <cpp@...ardszolnoki.com>
To: musl@...ts.openwall.com, Alejandro Colomar <alx@...nel.org>
Cc: 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)
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.
>>
>> 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.
