Hi Thiago, Arthur, Rich,

On Thu, Oct 30, 2025 at 09:54:56AM -0700, Thiago Macieira via Std-Proposals wrote:
> 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.

You could float the idea of an in-place realloc that would guarantee
that the address of the first byte remains the same, and thus that old
pointer values are still valid.

 void *realloci(void *p, size_t n);

You could keep it returning a pointer, for drop-in compatibility, and
also for convenience in chained code, although you could also make it
return an int (0 or -1).

I wonder if it should use a separate arena. I've CCed musl's maintainer
to see if they have any opinion about this, since they need to move the
pointers if the size of the allocation changes enough, due to how they
encode the actual size of the allocation.

If libc implementations find this easy to implement, it could be good.
Then, if you want to keep the object in place, just use realloci(), and
fall back to the normal realloc(3) if it fails, if you can, or just
fail.

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

I don't want this. Just realloc(3) round numbers to increase the
chances of allocating as much as you'll be given.

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

realloc(3) twice, maybe?

 N = 200;
 M = 100;

 q = realloc(p, N);
 if (q == NULL)
  q = realloc(p, M);
 if (q == NULL)
  goto fail;

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

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.

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.

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

Please clarify.


Have a lovely night!
Alex

> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals

-- 
<https://www.alejandro-colomar.es>
Use port 80 (that is, <...:80/>).