[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <icnw5plx6nfj2zdpdloo2uz3d3whh5vncdxuy5vzimarg3layn@phu7cnck3s7i>
Date: Fri, 31 Oct 2025 00:15:10 +0100
From: Alejandro Colomar <alx@...nel.org>
To: libc-alpha@...rceware.org, musl@...ts.openwall.com
Cc: Arthur O'Dwyer <arthur.j.odwyer@...il.com>,
Jonathan Wakely <jwakely@...hat.com>, Thiago Macieira <thiago@...ieira.org>
Subject: realloci(): A realloc() variant that works in-place
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.
- '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));
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.
Have a lovely night!
Alex
--
<https://www.alejandro-colomar.es>
Use port 80 (that is, <...:80/>).
Download attachment "signature.asc" of type "application/pgp-signature" (834 bytes)
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.
