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

[Alejandro Colomar]

Hi Thorsten,

On Fri, Oct 31, 2025 at 03:36:17PM +0100, Thorsten Glaser wrote:
> (no need to Cc me)
> 
> On Fri, 31 Oct 2025, Laurent Bercot wrote:
> 
> > As usual, and this applies to realloci() too, the question is: what
> > exact problem are you trying to solve?
> 
> Yes. This.

I don't know much C++; I'll let C++ committee members speak about it.

In C, I've sometimes seen programmers trying to check if realloc(3)
moved or not, to skip some work.  That's a micro-optimization that I've
never written myself, so I won't defend it.  But for some reason, some
programmers keep wanting to do it.

Have a lovely day!
Alex

> > > > How is that supposed to work if you want to grow the
> > > > allocation?
> > > >
> > > > This seems like increasing burden on the implementation
> > > > for everyone, just for niche corner use cases.
> > >
> > > realloc(3) already does this sometimes.  If the memory has some empty
> 
> > In most cases, it will be very difficult for an implementation to
> > increase the size of an allocated block without relocating the block.
> > So you can expect realloci() to fail often. What should users do in
> > that case?
> 
> Exactly. This makes me doubt its usefulness as a generic function.
> 
> Even were you to limit its use to shrinking allocations only, that
> would constrain implementations, e.g. those that spread the allocations
> based on their size and thus could not free anything.
> 
> So, in short:
> 
> When called with a larger size, it’ll just fail most of the time.
> 
> When called with a smaller size, it’ll just be a no-op in many cases.
> 
> bye,
> //mirabilos
> -- 
> 22:20⎜<asarch> The crazy that persists in his craziness becomes a master
> 22:21⎜<asarch> And the distance between the craziness and geniality is
> only measured by the success 18:35⎜<asarch> "Psychotics are consistently
> inconsistent. The essence of sanity is to be inconsistently inconsistent

-- 
<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/20251031/5944a134/attachment.sig>