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

[Lénárd Szolnoki]

On 30/10/2025 23:25, A. Wilcox wrote:
> On Oct 30, 2025, at 18:15, Alejandro Colomar <alx@kernel.org> wrote:
>>
>> Hi,
>>
>>
>> A discussion within the C++ std-proposals@ mailing list triggered the
>> discussion about the need for a realloc() variant that works in-place,
>> that is, that doesn't move the address of the memory, and thus that
>> doesn't invalidate existing pointers derived from it.
>>
>> It's not the first time I've had people want this.  While I worked on
>> fixing the situation of realloc(p,0) in the last year, several people
>> came to me saying they'd be interested in something like that.
>>
>> How about adding a realloci() function to musl and glibc, with the
>> following specification:
>>
>> void *realloci(void *p, size_t size);
>>
>> -  It returns the input pointer on success, or a null pointer on
>>    error.  Usual code using it would look like this:
>>
>> if (realloci(p, size) == NULL)
>> goto fail;
>>
>>    without needing to store the return value anywhere, and it's
>>    just like fgets(3) where it's mainly useful for the null
>>    check.
> 
> 
> So, if it fails, does it free the pointer?
> 
> If it doesn’t, then you can’t use it in simple assignment.
> 
> 
>>
>> -  'p' must be non-null.  This is because it doesn't make sense
>>    to keep in place a null pointer.
>>
>>    Forbidding null pointers here will also result in better
>>    static analysis: this function will never end any lifetime,
>>    and it will neither start any lifetime.  It's just a regular
>>    function, that happens to extend (or shrink) the storage of
>>    a block of memory.
>>
>> -  We could perfectly return int (0 for success, -1 for error),
>>    but returning the pointer makes it a drop-in replacement for
>>    realloc(3), and also allows using it in chained code
>>
>> foo(realloci(p, size));
> 
> 
> This is never safe if `realloci` can return `NULL`, IMO.
> 
> 
>>
>> About the name, I chose the 'i' because of sed(1) -i.  'i' seems to be
>> common for meaning in-place in several commands, so it would make sense
>> here, I think.
>>
>> I'd like to hear opinions from implementers about feasibility of this
>> API, before writing a standards proposal.  Please let me know any
>> feedback.
> 
> 
> Sigh.  The only safe way I can think to make this work is:
> 
> * It leaves the existing allocation alone if it can’t satisfy the
>     new size.
> 
> * It always returns the existing pointer, allowing for the above
>     example chain.
> 
> * It is one of those dances where you need to zero out errno first,
>     and pay attention to *that* as the “side channel” return value, to
>     know whether the pointer actually points to memory of the desired
>     size or not.
> 
> But all of that is complicated, easy to get wrong, and just introduces
> more foot guns to C.  Aren’t there enough already?
> 
> I like what you’ve done with `realloc`, but I think something like
> this belongs in a higher level language than C.

Some higher level language implementations (like libstdc++ and libc++ for C++) build on to 
of the C library's allocator, so they can't feasibly add a "try to extend allocation 
inplace" operation without cooperation from the C library.

I agree that the proposed interface might have problems, but the capability is useful, 
even for higher level languages to build up on.

Cheers,
Lénárd

> Best,
> -Anna
> 
> 
>> Have a lovely night!
>> Alex
> 
> --
> Anna Wilcox (she/her)
> SW Engineering: C++/Rust, DevOps, POSIX, Py/Ruby
> Wilcox Technologies Inc.
>