[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ac6ecf0a-ca29-4b8a-8d09-ac6b480f8046@cs.ucla.edu>
Date: Fri, 31 Oct 2025 10:59:43 -0600
From: Paul Eggert <eggert@...ucla.edu>
To: Alejandro Colomar <alx@...nel.org>
Cc: libc-alpha@...rceware.org, musl@...ts.openwall.com,
"A. Wilcox" <AWilcox@...cox-tech.com>,
Lénárd Szolnoki <cpp@...ardszolnoki.com>,
Collin Funk <collin.funk1@...il.com>,
Arthur O'Dwyer <arthur.j.odwyer@...il.com>,
Jonathan Wakely <jwakely@...hat.com>, "Paul E. McKenney"
<paulmck@...nel.org>, Thiago Macieira <thiago@...ieira.org>
Subject: Re: Re: realloci(): A realloc() variant that works in-place
On 10/31/25 10:22, Alejandro Colomar wrote:
> Paul, for context, this is a discussion for adding a function
>
> int realloci(void *p, size_t n);
>
> that changes the size of a memory block without moving it. (And thus,
> fails rather often, for some implementations of allocators.)
Reading the threads leading into this, the motivation for this seems to
be C++ and similar memory allocators that want a cheap way to grow an
object - if the object doesn't move they can skip some reinitialization
work, otherwise they have more work to do.
With that in mind, the proposed API is not the best way to go about the
problem. What these users want is a function that acts just like
R=realloc(P,N) EXCEPT that it lets you compare R==P, and if the two
values are the same pointer you know the object did not move and you can
skip some work. This is simpler than realloci because it means that you
need only one call (not two) in the common case when realloci returns
the null pointer.
In other words, these uses want the realloc function the way it was in
7th Edition Unix, before sanitizers got in the way and insisted that
it's an error to compare realloc's first argument with its result even
if they happen to have the same value.
There's an easy way to change the C standard to support these uses: just
change the spec for realloc to support this usage. There is no need to
change the C library, or musl, or any of the commonly used production C
libraries. The only change you'd need to make is to the C standard and
to picky sanitizers.
This would be *much* better than adding a new, hard-to-explain realloci API.
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.
