[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <lhupl9ntrth.fsf@oldenburg.str.redhat.com>
Date: Wed, 12 Nov 2025 12:26:34 +0100
From: Florian Weimer <fweimer@...hat.com>
To: Brooks Davis <brooks@...ebsd.org>
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
* Brooks Davis:
>> > 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.
The tag change would end up in ptrdiff_t. I think MTE still uses 64-bit
arithmetic for pointers.
(And what I wrote above is wrong for most (all?) Linux 64-bit
architectures: offsets between object pointers are always representable
in ptrdiff_t.)
Thanks,
Florian
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.
