On Fri, Oct 31, 2025 at 11:31 PM Jeremy Rifkin wrote:
>
> The reloc named constants you provided still have these magic numbers in the name which is a bit odd.


Perhaps out of ordinary, but efficient. If you glance at the
constant's name, you don't need to go looking in a header file or on
'cppreference.com' to figure out what the number is.

I've done more work on my paper. I've added descriptions of the
different categories (1 = memcpy, 2 = compiler builtin, and so on).
Latest draft is here:

    https://www.virjacode.com/papers/relocatability.htm

Furthermore I've pointed out a weakness in 'restart_lifetime', in that
it's not future-proof, as follows:

restart_lifetime is declared as follows:

    template<typename T>
    T *restart_lifetime(T *p) noexcept;

This function is a no-op on all platforms except for arm64e. On
arm64e, the object’s new address is enough information to correctly
re-encrypt the vtable pointer. However in the future, there might be
an architecture with a more complicated pointer authentication system,
and the re-encrypting of the vtable pointer might also require the
object’s old address. And so the declaration would need to change to:

    template<typename T>
    T *restart_lifetime(T *old, T *new) noexcept;

This is why restart_lifetime shouldn't be exposed to the programmer,
and all this stuff should be done inside std::relocate.