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

[Thiago Macieira]

On Tuesday, 4 November 2025 09:24:25 Pacific Standard Time Thiago Macieira 
wrote:
> I'll have more information for a more complex application once I finish
> rebuilding everything.

Here are some results with Qt Creator, which is the most complex Qt 
application I can test on the drop of a dime.

It called the new function 119 times just to print --help. When I launch it 
and immediately close its window, it got called 1152 times.

Looking at those first 119 calls, my previous observation stands: quite a few 
of those *could* have been realloc(), but aren't because we lack in C++ a way 
to detect that the type could be memcpy'ed about and still be valid (and won't 
have one until C++29). Qt has a mechanism to opt-in, but the authors of these 
types haven't.

This means this count does not include the reallocations that did use 
realloc() because the types used the Qt opt-in, and that includes very common 
containers like QStringList. So while this new function would be useful for 
Qt-based applications, it would be *more* useful for non-Qt C++ ones 
(presuming the C++ Standard finds a way to do so), especially because 
std::string is not guaranteed to work after being memcpy()ed around.

What I can't tell is whether a realloci() call would have succeeded. These 
calls happen when the container is growing, meaning it's about to create one 
or more non-trivial objects in the allocated memory, and the chances are 
really good that such objects will themselves allocate memory. For the first 
couple of growths, the new elements' memory use will likely prevent the 
container from extending in size. However, once the container has grown past a 
certain size and freed previous allocations, there may be heap space for the 
new objects to be created without occupying memory next to the container. 
Similarly, once the heap is sufficiently fragmented in a running application, an 
array of sufficient size will necessitate using a sufficiently large free region 
in the heap, but the objects' allocations can fit other, smaller free spaces.

-- 
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/20251104/e7e8b470/attachment.sig>