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

[Alejandro Colomar]

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.


Have a lovely day!
Alex

> With this interface, std::vector would not have to know the size
> classes of the allocator.  On failure, std::vector resizing would have
> to fall back to malloc/free and moving objects one by one.  But that
> is kind of inevitable.

-- 
<https://www.alejandro-colomar.es>
Use port 80 (that is, <...:80/>).
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <https://sourceware.org/pipermail/libc-alpha/attachments/20251101/53d398e4/attachment.sig>