Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-Id: <DDZC3TB3VV54.3FE6JQ61V5TW9@umich.edu>
Date: Mon, 03 Nov 2025 14:16:00 -0600
From: "Trevor Gross" <tmgross@...ch.edu>
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 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

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.