[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <oqy4sxagygotlhjwjir6rwxcwawv4d3ujao4env7aye2clb3a6@fbfuogjgpmh3>
Date: Fri, 31 Oct 2025 21:13:42 +0100
From: Alejandro Colomar <alx@...nel.org>
To: Paul Eggert <eggert@...ucla.edu>
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
Hi Paul,
On Fri, Oct 31, 2025 at 10:59:43AM -0600, Paul Eggert wrote:
> 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.
Yes.
> 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.
Consider that realloci() would be significantly cheaper than realloc(3),
so even if you have an extra function, it might be worth it if it
succeeds a non-negligible number of times.
From what Thiago says, it seems that it would be worth it for them.
I suspect it's because things like std::string often grow or shrink by
small amounts compared to the previous size, as operations on strings
don't change their length significantly quite often.
I've implemented realloci() in musl, and it's really trivial. After
all, it only checks the metadata to know if there's enough available
space after the block. It doesn't need to find a new block, which is
the hard part of realloc(3).
So, while it would be one more call in user code, that call is very
cheap, and the code is really simple to use too:
if (realloci(p, size) == -1)
fall_back_to_expensive_path();
> 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.
That would make sanitizers and static analyzers unable to verify lots of
code, for the benefit of just a few. I think a separate API would be
better, because it would let realloc(3) be stricter, which would provide
analyzers the ability to verify C code much better. Those that need to
be able to do weird things (C++), can opt in to the relaxed stuff by
using the niche function.
> This would be *much* better than adding a new, hard-to-explain realloci API.
I wouldn't categorize it as hard to explain:
int realloci(void *p, size_t size);
realloci() changes the size of the memory block pointed to by
'p' to 'size' bytes. This is done in-place, that is, without
changing its address.
The contents of the memory will be unchanged in the range from
the start of the region up to the minimum of the old and new
sizes. If the new size is larger than the old size, the added
memory will not be initialized.
'p' must have been returned by an earlier call to malloc(3) or
related functions.
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.
