[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <85499839-8c3d-411d-b0dc-82b737143d5f@paulmck-laptop>
Date: Fri, 31 Oct 2025 10:29:39 -0700
From: "Paul E. McKenney" <paulmck@...nel.org>
To: Alejandro Colomar <alx@...nel.org>
Cc: Thiago Macieira <thiago@...ieira.org>, 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 05:22:40PM +0100, Alejandro Colomar wrote:
> Hi Thiago, Thorsten, Paul,
>
> On Fri, Oct 31, 2025 at 09:02:42AM -0700, Thiago Macieira wrote:
> > On Friday, 31 October 2025 08:45:09 Pacific Daylight Time Thorsten Glaser
> > wrote:
> > > >In C, I've sometimes seen programmers trying to check if realloc(3)
> > > >moved or not, to skip some work. That's a micro-optimization that I've
> > > >never written myself, so I won't defend it. But for some reason, some
> > > >programmers keep wanting to do it.
> > >
> > > Huh. That one if is probably more effort than just doing the
> > > arithmetics always… if it’s not actually UB…
> >
> > The conclusion among C++ developers is that using the previous pointer in any
> > way is UB. Therefore, you simply cannot know if the area was moved or not.
>
> Yes, it is UB. realloc(3) zaps old pointers. Paul McKenney is
> proposing to not zap the old pointer in some cases, but with current
> ISO C, it is UB.
>
> I don't remember well the details of what Paul told me in Paris, so I've
> CCed him, in case he can clarify, or maybe if he has some reasons to
> defend wanting to use the old pointer.
>
> 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.)
The proposal that would address this in C++ (sadly, not in C) is this:
https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2025/p3790r1.pdf
("Pointer lifetime-end zap proposed solutions: Bag-of-bits pointer class").
You could then write something like this:
ptr_bits<char> p = malloc(12 * sizeof(*p);
ptr_bits<char> q;
q = realloc(p, 16 * sizeof(*p));
if (p != q)
do_something(p, q);
This works because ptr_bits<T> defines comparison in terms of the actual
in-memory representation, just like .compare_exchange() would do on an
atomic pointer of the same underlying type.
I will turn my attention to C after C++. C, C++, and Rust have slightly
different definitions of pointer provenance, so one at a time!
In the meantime, in theory you can get this effect as follows:
char *p = malloc(12 * sizeof(*p);
uintptr_t p_rep = (uintptr_t)p;
char *q;
uintptr_t q_rep;
q = realloc(p, 16 * sizeof(*p));
qrep = (uintptr_t)q;
if (prep != qrep)
do_something(prep, qrep);
Just so you all know, many long-time C and C++ programmers are completely
and absolutely flabbergasted to learn that just comparing the pointers
is UB. We have an education problem. I have done my part:
https://people.kernel.org/paulmck/what-on-earth-does-lifetime-end-pointer-zap-have-to-do-with-rcu
In addition to large numbers of working papers, that is. ;-)
Thanx, Paul
> Thiago, if you need this, it would also be useful to clarify what it
> would be useful for, and numbers if the micro-optimizations are
> important for you.
>
> Here's the start of the thread, for anyone reading new:
> <https://inbox.sourceware.org/libc-alpha/tzrznth5ng3qukc4dlym5woctbppcabjglsxgfnfvdrd45rr5d@573xvnl5twv6/T/#m625715f975b04cd7dd3d96276a7a83ace9f40d52>
>
>
> Have a lovely day!
> Alex
>
> --
> <https://www.alejandro-colomar.es>
> Use port 80 (that is, <...:80/>).
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.
