C++ Logo

std-proposals

Advanced search

Re: [std-proposals] consteval int relocatability

From: Frederick Virchanza Gotham <cauldwell.thomas_at_[hidden]>
Date: Mon, 10 Nov 2025 09:01:14 +0000
On Mon, Nov 10, 2025 at 8:39 AM Frederick Virchanza Gotham wrote:
>
> I have further edited my compiler patch, and now
> __builtin_restart_lifetime runs without crashing.


One other thing we need to talk about though is 'qsort' as follows:

    template<class T>
    void my_sort(T *first, T *last)
    {
      auto *cmp = +[](const void *va, const void *vb) {
        T const &a = *std::restart_lifetime<T>(static_cast<void*>(va));
        T const &b = *std::restart_lifetime<T>(static_cast<void*>(vb));
        return a < b;
      };
      std::qsort(first, last - first, sizeof(T), cmp);
    }

In the above snippet, 'restart_lifetime' must be called every time an
object is relocated by the 'qsort' algorithm -- but the problem is
that we don't have its previous address. What we have here is a form
of 'restart_lifetime' that only takes one argument instead of two. But
I think for pointer authentication on arm64e, we need the old address,
right? I wonder why arm64e just can't take the vtable address (which
is known at compiler time from the template type T) and write a new
authenticated pointer at runtime?

I wonder had anyone considered altering the specification of 'qsort'
so that it internally invokes 'restart_lifetime'? This would mean we
have access to the old address and can therefore pass two addresses to
'restart_lifetime'. Or would it be too funky to have a C library
function invoking a C++ library function like that? Well actually the
C library function would be invoking a compiler builtin:
__restart_lifetime.

Received on 2025-11-10 09:01:26