Date: Wed, 29 Oct 2025 15:37:42 +0100
Il 29/10/25 15:00, Frederick Virchanza Gotham via Std-Proposals ha scritto:
> On Wed, Oct 29, 2025 at 1:39 PM Giuseppe D'Angelo wrote:
>>
>>> On an arm64e computer, if you relocate a polymorphic object, and then
>>> invoke a virtual method, the attempt to access the vtable will cause a
>>> CPU trap because the vtable pointer will be incorrectly encrypted.
>>
>> This is not the case; the vtable pointer gets correctly re-signed during
>> trivial relocation.
>
>
> Trivial relocation means you can just move the object byte-by-byte
> without any further processing. There is no mutation of the bytes --
> they are moved verbatim without being edited.
No, to trivially relocate something means (as of the current working
draft) that you called std::trivially_relocate(). That operation is
allowed (in fact, it has been designed) to repatch virtual table
pointers and do whatever other runtime magic necessary to make
polymorphic types work.
You are of course free to say that this doesn't match your mental model
of triviality; nor the (non-standard) pre-existing practice in many
libraries; nor even the new practice (e.g. Proxy v3).
I'd even agree with such a position; that's why I wrote P3780.
My 2 c,
--
Giuseppe D'Angelo
> On Wed, Oct 29, 2025 at 1:39 PM Giuseppe D'Angelo wrote:
>>
>>> On an arm64e computer, if you relocate a polymorphic object, and then
>>> invoke a virtual method, the attempt to access the vtable will cause a
>>> CPU trap because the vtable pointer will be incorrectly encrypted.
>>
>> This is not the case; the vtable pointer gets correctly re-signed during
>> trivial relocation.
>
>
> Trivial relocation means you can just move the object byte-by-byte
> without any further processing. There is no mutation of the bytes --
> they are moved verbatim without being edited.
No, to trivially relocate something means (as of the current working
draft) that you called std::trivially_relocate(). That operation is
allowed (in fact, it has been designed) to repatch virtual table
pointers and do whatever other runtime magic necessary to make
polymorphic types work.
You are of course free to say that this doesn't match your mental model
of triviality; nor the (non-standard) pre-existing practice in many
libraries; nor even the new practice (e.g. Proxy v3).
I'd even agree with such a position; that's why I wrote P3780.
My 2 c,
--
Giuseppe D'Angelo
Received on 2025-10-29 14:37:46
