[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <8625a511-7b7a-4189-be77-9237f63efa12@paulmck-laptop>
Date: Fri, 31 Oct 2025 11:12:10 -0700
From: "Paul E. McKenney" <paulmck@...nel.org>
To: Thiago Macieira <thiago@...ieira.org>
Cc: Alejandro Colomar <alx@...nel.org>, Paul Eggert <eggert@...ucla.edu>,
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>
Subject: Re: Re: realloci(): A realloc() variant that works in-place
On Fri, Oct 31, 2025 at 10:25:27AM -0700, Thiago Macieira wrote:
> 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.
In C++, presumably, only std::movable types should be passed to realloc(),
right? In C, yes, this is a definitely an issue, but then again it has
been since the advent of realloc().
Thanx, Paul
> [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.
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.
