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

[Thiago Macieira]

On Tuesday, 11 November 2025 14:19:27 Pacific Standard Time Jeffrey Walton 
wrote:
> Now the C++ folks have a growable string that does not need reallocations.

If you know the end size, even a rough estimate of it, by all means use it. An 
overestimation is probably worth the trade-off for not needing to reallocate.

The problem is when the user doesn't know the end size, such as when parsing 
some input that doesn't come with a size prepended. Or when the user simply 
fails to call such function because it isn't *necessary*, just an 
optimisation.

BTW, that reminds me of the dual of container growth: the shrink_to_fit() 
operation. Some developers may reserve() too much and then shrink_to_fit() the 
memory. If the contained type can't be memmove()d around, the container 
implementation may opt to not give the memory back in the first place. If we 
did have realloci(), we could signal to the memory allocator that a portion of 
the memory is now free for new allocations - whether that implementation can 
make use of it will be implementation-dependent.

-- 
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
  Principal Engineer - Intel Data Center - Platform & Sys. Eng.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 870 bytes
Desc: This is a digitally signed message part.
URL: <https://sourceware.org/pipermail/libc-alpha/attachments/20251111/58ab2aaf/attachment.sig>