[musl] Re: realloci(): A realloc() variant that works in-place

[Florian Weimer]

* 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.

> 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.

Thanks,
Florian