[musl] alignment guarantees from realloc(3)

[musl] alignment guarantees from realloc(3)

[Alejandro Colomar]

[-- Attachment #1: Type: text/plain, Size: 973 bytes --]

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).


Have a lovely night!
Alex

-- 
<https://www.alejandro-colomar.es>
Use port 80 (that is, <...:80/>).

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [musl] alignment guarantees from realloc(3)

[Rich Felker]

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

Re: [musl] alignment guarantees from realloc(3)

[Lénárd Szolnoki]

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

Re: [musl] alignment guarantees from realloc(3)

[Alejandro Colomar]

[-- Attachment #1: Type: text/plain, Size: 2618 bytes --]

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/>).

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [musl] alignment guarantees from realloc(3)

[Rich Felker]

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

Re: [musl] alignment guarantees from realloc(3)

[Trevor Gross]

On Fri Oct 31, 2025 at 1:58 AM CDT, 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:
>>> [...]
>>> 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.

Is the intent with making this undefined to allow the allocator to
always grow in place, without first checking for sufficient alignment?

If so, that seems like a pretty cheap check to keep the flexibility.
Allowing any alignment gets rid of a footgun and means that the user
doesn't strictly _have_ to be aware of the original alignment (which may
require tracking on their end), just the destination alignment. In
theory you could even allow aligned_realloc on a buffer that came from
vanilla malloc.

There are some less common cases where it would be helpful to change the
alignment, e.g. reinterpreting a container as that of a more strictly
aligned type, but I think ease of use is the bigger win here.

- Trevor