C++ Logo

std-proposals

Advanced search

Re: [std-proposals] realloc(3)

From: Bo Persson <bo_at_[hidden]>
Date: Fri, 31 Oct 2025 14:10:32 +0100
On 2025-10-31 at 11:41, Marcin Jaczewski via Std-Proposals wrote:
> pt., 31 paź 2025 o 02:49 Marc Edouard Gauthier via Std-Proposals
> <std-proposals_at_[hidden]> napisał(a):
>>
>> Alejandro Colomar wrote:
>>> On Thu, Oct 30, 2025 at 11:01:19AM -0700, Thiago Macieira wrote:
>>>> On Thursday, 30 October 2025 10:43:51 Pacific Daylight Time Alejandro Colomar wrote:
>>> [...]
>>>>>>> - Almost always when I call `malloc` or `realloc`, I care about
>>>>>>> the alignment of the buffer. How can I communicate my alignment
>>>>>>> requirement to the system? (There is still no aligned_realloc.)
>>>>>>
>>>>>> "Should be fixed"
>>>>>>
>>>>>> Right now, we only try to realloc() for types whose alignment is
>>>>>> less than or equal to std::max_align_t's. Stricter types aren't
>>>>>> common enough to raise this to "Must fix".
>>>>>
>>>>> I assume the idea was that realloc(3) should remember the alignment
>>>>> of the memory, and honor it. Why would you want to change
>>>>> (presumably,
>>>>> increase) the alignment of an existing memory block? I assume that
>>>>> you'd want to just preserve whatever alignment aligned_alloc(3) gave
>>>>> you. That's an easy fix that could be added to the standard, I guess.
>>>>
>>>> I can't think of a scenario where the alignment requirement changes.
>>>> The issue is indeed that the aligned_alloc(3) alignment is not
>>>> guaranteed to be preserved.
>>>>
>>>> I note that Microsoft has _aligned_realloc():
>>>> https://learn.microsoft.com/en-us/cpp/c-runtime-library/reference/alig
>>>> ned-realloc?view=msvc-170
>>>>
>>>> But that requires using _aligned_free() to free memory. As far as I
>>>> know, they don't yet provide the C11 aligned_alloc(3) function.
>>>>
>>>>> We could add this:
>>>>>
>>>>> realloc(3) shall preserve the alignment of a block allocated
>>>>> previously by aligned_alloc(3).
>>>>>
>>>>> Please let me know if you want something like this, and we can
>>>>> discuss on writing a proposal.
>>>>
>>>> Yes, I'd like that, but I don't *need* that because there's an
>>>> alternative. So question should be first to malloc() maintainers: would this be doable?
>>>
>>> Thanks! I've also sent an email to glibc and musl about this (and again, also CCd you and others).
>>
>> Requiring preservation of alignment sounds nice but may not be universally desirable.
>> It will definitely break various simple allocator implementations, especially in the embedded world.
>> There may be simply no space to store alignment when each allocated block is separated by a single 32-bit word providing the sizes of this and the previous block, and various other such schemes. Asking an embedded allocator running on machines with limited memory resources to waste another 32-bits per allocated block is a no-go.
>>
>
> Would it be possible to recover this information from the pointer
> itself? If it had alignment to some specific limit then the allocator
> is required to return the same on the new pointer.
> It could sometimes have "false positives" but overall it probably
> should not have a negative impact on total memory usage.

I guess it would be more than "sometimes". Assuming that your very first
allocation from a fresh heap happens to be page aligned, what is its
"true" alignment?

Received on 2025-10-31 13:10:41