On Thu, Oct 30, 2025 at 07:27:38AM -0700, Thiago Macieira via Std-Proposals wrote:
> On Wednesday, 29 October 2025 14:24:23 Pacific Daylight Time Thiago Macieira
> via Std-Proposals wrote:
> > I disagree because I don't want to wait for that operation. I want
> > relocations now. In fact, I want them in 2005, when Qt began doing them
> > anyway. It's memcpy/memmove, period.
>
> Oh, and realloc(). That's actually the most important one.
>
> 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.
<https://www.austingroupbugs.net/view.php?id=1949>
<https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3621.txt>
That seems to address only the "unhappiest path" where the caller is literally trying to do realloc(p, 0). Nobody does that in practice [he says, hyperbolically].
I'm sure the API issues Thiago is talking about concern the "happy path." Things like:
- Sometimes when I call `realloc`, the buffer doesn't move, and so pointers/iterators/references aren't invalidated. How can I tell when this happens? (In practice I think this is easy, but technically at least in C++ it's UB even to read the pointer value of the old, freed pointer in order to equality-compare it with the new pointer.)
- Sometimes when I call `malloc` or `realloc`, I'd like N bytes, but I'd be satisfied to fall back to M. How can I communicate this to the system?
- 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.)
Thiago may have been thinking of even more/different API issues, too.