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

[Rich Felker]

On Sat, Nov 01, 2025 at 04:22:30PM +0100, Alejandro Colomar wrote:
> Hi Florian,
> 
> On Sat, Nov 01, 2025 at 02:05:57PM +0100, Florian Weimer wrote:
> > * Alejandro Colomar:
> > 
> > > A discussion within the C++ std-proposals@ mailing list triggered the
> > > discussion about the need for a realloc() variant that works in-place,
> > > that is, that doesn't move the address of the memory, and thus that
> > > doesn't invalidate existing pointers derived from it.
> > 
> > > 	void *realloci(void *p, size_t size);
> > 
> > The caller won't have sufficient information to determine good values
> > for size.
> > 
> > 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.
> 
> Would this work?:
> 
> 	ssize_t realloci(void *p, size_t size);
> 
> Where realloci() allocates at least 'size' bytes (but possibly more),
> and returns the actual usable size of the block.  So, you could
> 
> 		realloci(p, 3000);
> 
> and it would return for example 4096, which would be the usable size of
> the block.  Or it would return -1 if it is unable to grow that much.
> realloci() would never fail when shrinking, as it could just return a
> larger size and be done with it.

ssize_t is POSIX-only and unlikely to be adopted by C standard. It
could return (size_t)-1 instead.

Actually returning a value larger than n seems bad (makes it
impossible to detect OOB writes beyond the actually requested size)
though so this seems like a dubious feature.

Rich