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

[Alejandro Colomar]

Hi Thiago,

On Wed, Nov 05, 2025 at 09:38:42AM -0800, Thiago Macieira wrote:
> On Wednesday, 5 November 2025 03:24:14 Pacific Standard Time Alejandro Colomar 
> wrote:
> > Agree.  Before adding realloci(), I'd like to see numbers.  An
> > interesting thing to do would be to see some application that uses
> > realloc(3) currently, and check how often realloc(3) doesn't move the
> > object.  (To test that without UB, one needs to do the trick with
> > uintptr_t.)
> 
> I can give you some numbers for realloc() success, with the understanding that 
> they are NOT AT ALL the cases where realloci() would be used. I can't emit a 
> realloc() call that MAY relocate an an array of objects, if the objects don't 
> allow relocating. That would crash the application on the first time realloc() 
> did relocate. So I can only do it for the cases where the implementation would 
> keep using realloc() in the future.
> 
> The only way to test how often realloci() would succeed is to have realloci().
> 
> Anyway, my test is running qtcreator. Remember that it called the placeholder 
> function that would call realloci() 119 times just for running --help.
> 
> It also called QArrayData::reallocateUnaligned() with objectSize > 4 a total 
> of 1577 times, in 115 of which realloc() returned the same pointer (7.3%). In 
> fact, a quick glimpse of the gdb output shows that the same pointer succeed in 
> growing more than once in a row: I see a pointer at least 4x twice in a row, 
> with an increased capacity parameter, suggesting that it's the same array. 
> 
> In the full run (without --help), realloc() extended in place 1045 out of 
> 10088 calls, increasing to 10.3% extension success rate.

Thanks!  10% sounds useful enough IMO.  That's motivation enough for me
to write the proposal for ISO C, and continue working on the musl
patches.


Have a lovely night!
Alex

-- 
<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/20251106/efa43970/attachment-0001.sig>