[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <2972143c-813d-4953-8c77-7afdb6710768@lenardszolnoki.com>
Date: Fri, 31 Oct 2025 06:47:55 +0000
From: Lénárd Szolnoki <cpp@...ardszolnoki.com>
To: musl@...ts.openwall.com, "A. Wilcox" <AWilcox@...cox-Tech.com>
Cc: libc-alpha@...rceware.org, Arthur O'Dwyer <arthur.j.odwyer@...il.com>,
Jonathan Wakely <jwakely@...hat.com>, Thiago Macieira <thiago@...ieira.org>
Subject: Re: realloci(): A realloc() variant that works in-place
On 30/10/2025 23:25, A. Wilcox wrote:
> On Oct 30, 2025, at 18:15, Alejandro Colomar <alx@...nel.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.
>
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
