realloci(): A realloc() variant that works in-place

[Florian Weimer]

* Thiago Macieira:

> On Saturday, 1 November 2025 06:05:57 Pacific Daylight Time Florian Weimer 
> wrote:
>> For the std::vector case at least, what applications want is some form
>> of non-moving realloc that allows the application to specify an
>> arithmetic progression and an interval, and the realloc variant should
>> change the size of the allocation to an element of the arithmetic
>> progression that resides within the specified interval, or fail.
>
> That would indeed be better. When growing, the class doesn't know
> how many more items are coming, so a best effort from the runtime is
> welcome. There's a chance that the smaller allocation that the
> runtime was able to fulfill will suffice and thus we'll have avoided
> an extra relocation of the elements.
>
> Wouldn't this be the xallocx() interface from jemalloc? It allows
> the caller to pass the number of elements/bytes it really needs and
> the number of elements/bytes it speculates it will need.
>
> However, it's not necessary.

I assume the document here is current? <https://jemalloc.net/jemalloc.3.html>

The description is not very precise.  I think for avoiding
fragmentation, it would be desirable for xallocx to return values
great than size + extra if there's a tail that cannot be used by
another allocation.  It's unclear whether that's permitted.
But with a few clarifications, xallocx might indeed be a simpler
interface for this.