On 30/10/2025 16:23, Thiago Macieira via Std-Proposals wrote:
> On Thursday, 30 October 2025 07:59:19 Pacific Daylight Time Alejandro Colomar
> wrote:
>>> I'll accept a replacement function if realloc() can't be fixed.
>>
>> I don't know if realloc(3) has any issues in C++, but if you mean the
>> issues that C also has, we're in the process of fixing them.
>
> I didn't. I need a function that will expand a previously memory block or tell
> me that it couldn't. If this function can relocate it in memory, it must work
> for C++ trivially-relocatable types (whichever definition it is).
>
> One simple solution is to define it to only resize-in-place. If it can't do
> that, then the caller can malloc() a new region and relocate/move-construct
> the content in the new area, then free() the old. For the majority of malloc()
> implementations, this suffices because the backend usually just does what we'd
> do: malloc() a new block and memcpy() to it. But there could be
> implementations that just reassign physical pages to new areas in virtual
> memory, which would not benefit from "only resize-in-place" solutions.

AFAIK glibc's malloc and realloc for sufficiently large allocations directly use mmap and
mremap, without any memcpy.

I think it makes sense to wrap and expose the mremap capability (with MREMAP_MAYMOVE) in
the allocator. I don't think it can be broken down to smaller operations, it really is a
transaction.

Having said that, having only this operation is indeed limited. A "try resize allocation
inplace" operartion would indeed be useful.

>
> Either way, the resize-in-place must have a good chance of succeeding in major
> implementations. If libstdc++ and libc++ have to implement it as "return
> false" for a good number, it's not a good solution.
>
> In my mind, reallocating memory and trivial relocatability go hand in hand.
> Any solution for the latter that breaks the former is DOA and WILL NOT BE USED
> in Qt.
>
> --
> Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
> Principal Engineer - Intel Data Center - Platform & Sys. Eng.
>
>
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals