[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <3079272.0QQBjFxQff@tjmaciei-mobl5>
Date: Fri, 31 Oct 2025 10:25:27 -0700
From: Thiago Macieira <thiago@...ieira.org>
To: Alejandro Colomar <alx@...nel.org>, 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>
Subject: Re: Re: realloci(): A realloc() variant that works in-place
On Friday, 31 October 2025 09:59:43 Pacific Daylight Time Paul Eggert wrote:
> 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.
If you meant a "resize-in-place or malloc new" function, I might agree. That
would reduce the number of function calls in the example I posted in the other
email, eliminating the malloc() call. Though it remains to be seen if that's
actually better, because there are cases where the malloc()+move+free() is
still needed, so the code could be shared across multiple uses and thus reduce
codegen size. Then there's the case of shrinking, where knowing that the
operation is guaranteed to be O(1) is beneficial.
But not this:
> In other words, these uses want the realloc function the way it was in
> 7th Edition Unix
>From the C++ side, we *cannot* allow the object to be relocated in memory
without its permission. We need to know the function *will not* move the
memory region before calling it, because there's currently no way to
generically adjust the relocated objects after the fact. That is why realloc()
is currently little used in C++.
That would require a new extension point for almost every class, which means
it becomes an opt-in and only available for code written to support C++29 at
the earliest.
That's assuming it's even possible. How would one adjust sub-objects of an
object? One thing that keeps coming up are the ARM64e authenticated
pointers[1], and from my limited understanding of the feature, it might not be
possible to write the new authenticated pointer to the new location without
reading from the old. I think the Committee would balk at adding a function
that takes a pointer to already-freed memory whose purpose is to allow the
contents of the new object to be adjusted solely based on arithmetic.
[1] https://clang.llvm.org/docs/PointerAuthentication.html
--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Principal Engineer - Intel Data Center - Platform & Sys. Eng.
Download attachment "signature.asc" of type "application/pgp-signature" (871 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.
