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

[Rich Felker]

On Mon, Nov 03, 2025 at 12:58:39AM +0100, Alejandro Colomar wrote:
> > All this will need fine-tuning once implementations exist.
> > 
> > > So, why not require the caller to not ask too much?  We could go back to
> > > reporting an error if there's not enough memory.
> > > 
> > > Of course, it would still guarantee no errors when shrinking, but
> > > I think we could error out when growing.
> > 
> > I'd prefer no errors either way. If there isn't memory to grow the underlying 
> > space (a brk() system call returns ENOMEM), then realloci() returns as much as 
> > it could get but not more.
> 
> The problem is that this is asking the implementation to speculate.
> 
> Consider the case that a realloci() implementation knows that the
> requested size fails.  Let's put some arbitrary numbers:
> 
> 	old_size = 10000;
> 	requested_size = 30000;
> 
> It knows the block can grow to somewhere between 10000 (which it
> currently has) and 30000 (the system reported ENOMEM), but now it has
> the task of allocating as much as it can get.  Should it do a binary
> search of the size?  Try 20000, then if it fails try 15000, etc.?
> That's speculation, and it would make this function too slow.

I don't see any plausible implementation in which this involved a
binary search. Either you have fixed-size slots in which case you just
look at the size of the slot to see what the max obtainable is, or you
have a dlmalloc-like situation where you check the size of the
adjacent free block (if any) to determine the max obtainable. These
are O(1) operations.

Rich