[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <aRRh5DPUILRlU3d4@spindle.one-eyed-alien.net>
Date: Wed, 12 Nov 2025 10:31:00 +0000
From: Brooks Davis <brooks@...ebsd.org>
To: Florian Weimer <fweimer@...hat.com>
Cc: musl@...ts.openwall.com, Thiago Macieira <thiago@...ieira.org>,
Alejandro Colomar <alx@...nel.org>, libc-alpha@...rceware.org,
"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 Tue, Nov 11, 2025 at 02:55:03PM +0100, Florian Weimer wrote:
> * Brooks Davis:
>
> > On Fri, Oct 31, 2025 at 09:54:52PM -0600, Paul Eggert wrote:
> >> On 10/31/25 17:27, Thiago Macieira wrote:
> >> > I don't think you are because imposing this requirement would imply it will
> >> > never memcpy() the data to a new location and that would break quite a lot of
> >> > applications that depend the ability to grow a block so long as there's heap
> >> > available.
> >>
> >> You're right I'm not saying that. All I'm saying is that when R=realloc(P,N)
> >> succeeds, you can assume that you can adjust old pointers into the object
> >> addressed by P by adding R-P to them. The C standard says this results in
> >> undefined behavior; all that we need to do is fix the C standard to say it's
> >> well-defined (because it is on practical platforms).
> >
> > As described (adding R-P), this is broken on CHERI systems. You must
> > derive new pointers from R as pointers derived from P will be out of
> > bounds (and with revocation will become invalid at some indeterminate
> > point.) In CheriBSD, we do take care to preserve the invariant that
> > either the pointer is unchanged including bounds or we've done a
> > malloc-memcpy-free.
>
> Would this work?
>
> new->field = (decltype(new->field)) ((char *) new
> + ((uintptr_t) new->field
> - (uintptr_t) old));
>
> That should have correct provenance.
Yes, this works (I'd tend to write that with ptraddr_t casts instead
of uintptr_t casts as the provenance is slightly ambigious, but those
aren't standard yet (hopefully coming in C++2Y)). I think people have
historically choosen the other option because it saves a subtraction in
a loop over values that require updating. In our heap temporal safety
work we've taken care to ensure that this work even if the old values
are invalidated during the update.
> > MTE is likely to have similar issues with pointer updates unless the
> > implementer ensures that realloc returns pointers of the same color.
>
> Only if pointer additions wrap around, but that would be a problem even
> without MTE: ptrdiff_t cannot represent all potential pointer offsets
> anyway.
The issues is that if new and old are different colors, you must derive
the updates from new and not old or you'll have the wrong color.
-- Brooks
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.
