|
|
Message-ID: <aRMmOdUc4I4wGO2c@spindle.one-eyed-alien.net> Date: Tue, 11 Nov 2025 12:04:09 +0000 From: Brooks Davis <brooks@...ebsd.org> To: musl@...ts.openwall.com Cc: 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 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. MTE is likely to have similar issues with pointer updates unless the implementer ensures that realloc returns pointers of the same 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.