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.

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.