On Thursday, 30 October 2025 08:50:17 Pacific Daylight Time Arthur O'Dwyer via
Std-Proposals wrote:
> - 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.)

"Would be nice"

It's "UB but works everywhere". I'm not worried about this, but it should be
fixed.

> - Sometimes when I call `malloc` or `realloc`, the returned buffer actually
> has more capacity than I asked for. How can I tell the true capacity of the
> buffer? <https://stackoverflow.com/a/48612539/1424877>

I don't need this.

> - 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?

"Would be nice"

I've never needed this. I can see the benefit, though. Or conversely, combined
with the previous one, I can ask for M and the allocator can tell me "sure,
but due to unimportant implementation details, you've got more than that (N)".

> - 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".

> Thiago may have been thinking of even more/different API issues, too.

Specifically growing a buffer.

-- 
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
  Principal Engineer - Intel Data Center - Platform & Sys. Eng.