[musl] Re: realloci(): A realloc() variant that works in-place

[Paul E. McKenney]

On Fri, Oct 31, 2025 at 10:25:27AM -0700, Thiago Macieira wrote:
> On Friday, 31 October 2025 09:59:43 Pacific Daylight Time Paul Eggert wrote:
> > Reading the threads leading into this, the motivation for this seems to
> > be C++ and similar memory allocators that want a cheap way to grow an
> > object - if the object doesn't move they can skip some reinitialization
> > work, otherwise they have more work to do.
> > 
> > With that in mind, the proposed API is not the best way to go about the
> > problem. What these users want is a function that acts just like
> > R=realloc(P,N) EXCEPT that it lets you compare R==P, and if the two
> > values are the same pointer you know the object did not move and you can
> > skip some work. This is simpler than realloci because it means that you
> > need only one call (not two) in the common case when realloci returns
> > the null pointer.
> 
> If you meant a "resize-in-place or malloc new" function, I might agree. That 
> would reduce the number of function calls in the example I posted in the other 
> email, eliminating the malloc() call. Though it remains to be seen if that's 
> actually better, because there are cases where the malloc()+move+free() is 
> still needed, so the code could be shared across multiple uses and thus reduce 
> codegen size. Then there's the case of shrinking, where knowing that the 
> operation is guaranteed to be O(1) is beneficial.
> 
> But not this:
> 
> > In other words, these uses want the realloc function the way it was in
> > 7th Edition Unix
> 
> >From the C++ side, we *cannot* allow the object to be relocated in memory 
> without its permission. We need to know the function *will not* move the 
> memory region before calling it, because there's currently no way to 
> generically adjust the relocated objects after the fact. That is why realloc() 
> is currently little used in C++.
> 
> That would require a new extension point for almost every class, which means 
> it becomes an opt-in and only available for code written to support C++29 at 
> the earliest.
> 
> That's assuming it's even possible. How would one adjust sub-objects of an 
> object? One thing that keeps coming up are the ARM64e authenticated 
> pointers[1], and from my limited understanding of the feature, it might not be 
> possible to write the new authenticated pointer to the new location without 
> reading from the old. I think the Committee would balk at adding a function 
> that takes a pointer to already-freed memory whose purpose is to allow the 
> contents of the new object to be adjusted solely based on arithmetic.

In C++, presumably, only std::movable types should be passed to realloc(),
right?  In C, yes, this is a definitely an issue, but then again it has
been since the advent of realloc().

							Thanx, Paul

> [1] https://clang.llvm.org/docs/PointerAuthentication.html
> -- 
> Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
>   Principal Engineer - Intel Data Center - Platform & Sys. Eng.