On Thursday, 30 October 2025 10:43:51 Pacific Daylight Time Alejandro Colomar
wrote:
> > 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);

Yes, this is the resize-in-place I've mentioned. It's good enough for me and
for all the systems I currently have access to, Qt currently runs on, and are
currently on the horizon. In fact, we do need this, because for non-
relocatable types, if the memory block can be extended, we won't need to
relocate them elsewhere in the first place.

But as I argued in the previous email, it's conceivable for realloc() to just
change the page tables and thus achieve a O(1) moving in virtual memory.
Therefore, the C++ trivial relocatability feature must somehow work with
realloc(), either by providing a function that performs the reallocation and
relocation, or by providing a function or two we must call before or after the
reallocation.

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

I've seen this in some implementations of malloc(), that different memory
blocks necessarily use different arenas/slabs, and therefore growing a previous
allocation past a given size will trigger moving to a different arena/slab,
even if the current one had free space afterwards. That just means resize-in-
place will fail more often than for other implementations.

Whether that is something that we need to take care of at the higher layer
(the container) or not remains to be seen. For example, we could adjust how
aggressively we overallocate the initial blocks.

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

I *think* this is easy to implement, because the machinery to perform the
resize-in-place is already there for the realloc(3) implementations. It looks
like just breaking up realloc() into two pieces would accomplish the goal.

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

I can't think of a scenario where the alignment requirement changes. The issue
is indeed that the aligned_alloc(3) alignment is not guaranteed to be
preserved.

I note that Microsoft has _aligned_realloc():
https://learn.microsoft.com/en-us/cpp/c-runtime-library/reference/aligned-realloc?view=msvc-170

But that requires using _aligned_free() to free memory. As far as I know, they
don't yet provide the C11 aligned_alloc(3) function.

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

Yes, I'd like that, but I don't *need* that because there's an alternative. So
question should be first to malloc() maintainers: would this be doable?

Because if it isn't, we can pass the alignment requirement again for an
aligned_realloc() function like Microsoft does.

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

Only applies to C++, so see other emails.
    realloc(buf, newsize);
where "buf" contains "trivially relocatable" objects.

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