Similarly, it is perfectly safe to cast a correctly aligned uint8_t* to uint64_t* and dereference it as long as you originally stored an uint64_t into it (or the compiler can't prove you didn't). Remember aliasing UB is always on derefencing with the wrong dynamic type, not on casting pointers.
You can cast any pointer you like to any other pointer. When you dereference it, if the declared type is not the type of the underlying object, bad times for you.
An interface which takes a uint8_t* and immediately invokes UB if you pass it anything other than a pointer to a uint64_t can indeed be written, but one should expect people to pass it things other than a cast uint64_t*.
Further, the magic aliasing char doesn't work in both directions. If this code was changed to take a char instead of a uint8_t it would be exactly as undefined as it is currently. You can aim a char* into a uint64_t and deref the char, but you can't aim a uint64_t* into a char and deref the uint64_t.*
Edit: That's what I remember but I can't find evidence of it. The docs say this is ABI dependent so perhaps the above statement is true on some specific ABI (if I haven't misremembered it entirely). But I can't track down wheere a relevant ABI would be documented.
https://gcc.gnu.org/onlinedocs/gcc-13.2.0/gcc/Architecture-i...
Edit 2: this header has a typedef of uint8_t to unsigned char, but it's part of glibc rather than gcc
https://android.googlesource.com/platform/prebuilts/gcc/linu...
uint64_t x=0;
uint8_t * p = (uint8_t*)&x;
uint64_t y = *(uint64_t*)p;
But today, uint8_t is in practice always a char type. You can static_assert if you want to be completely sure. Or just use std::byte.