[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <E0F35CEA-5483-47D9-BD05-35E752F1E63F@Wilcox-Tech.com>
Date: Thu, 30 Oct 2025 18:25:27 -0500
From: "A. Wilcox" <AWilcox@...cox-Tech.com>
To: musl@...ts.openwall.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 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.
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.
