Why isn't ptr::addr const?

[Miiao]

Why can't

    #[must_use]
    #[inline]
    #[unstable(feature = "strict_provenance", issue = "95228")]
    pub fn addr(self) -> usize
    where
        T: Sized,
    {
        unsafe { mem::transmute(self) }
    }

be replaced with

    #[must_use]
    #[inline]
    #[unstable(feature = "strict_provenance", issue = "95228")]
    pub const fn addr(self) -> usize
    where
        T: Sized,
    {
        unsafe {
            union Repr_ {
                ptr: Self,
                adr: usize
            }
            Repr_ {ptr: self}.adr
        }
    }

?

[H2CO3]

Why would you want to replace it in the first place? Reading from a differently-typed field of a union has the same effect as transmute(), it's just more code.

[Miiao]

core::mem::transmute isn't const, is it?

[H2CO3]

What do you mean by "isn't copy"?

[Cerber-Ursi]

transmute definitely is semantically a bitwise copy from argument to return value. Do you mean "isn't const"?

[Miiao]

A typo

@Cerber-Ursi, yes, that's what i meant

[H2CO3]

transmute is const since 1.56. This is in the docs.

[Miiao]

Anyway why isn't ptr::addr const then?

[CAD97]

addr isn't const because pointers aren't integers. In the const evaluation engine, pointers don't even have an address to provide.

[wesleywiser]

This is also discussed in a recent Rust blog post:

this operation is not supported: the transmute above is trying to reinterpret the memory address &() as an integer of type usize . The compiler cannot predict what memory address the () would be associated with at execution time, so it refuses to allow that reinterpretation.
...
You might well be wondering at this point: "Wait, when is it okay to transmute a pointer to a usize during const evaluation?" And the answer is simple: "Never."
Transmuting a pointer to a usize during const-eval has always been undefined behavior, ever since const-eval added support for transmute and union.

Const Eval (Un)Safety Rules | Rust Blog (rust-lang.org)

[Miiao]

@CAD97, @wesleywiser, well... ok...

[VorfeedCanal]

@Miiao

Anyway why isn't ptr::addr const then?

It's a bit sad that transmute (or your union trick) can be used to transmute between pointers and integers at compile time (and it's not a compile-time errors like in C++) but it's point where Rust is worse than C++: certain undefined behaviours are not detected.

C++ does better: undefined behaviour doesn't exist in complie-time C++! You can not convert between pointers and integers in compile-time C++ (and it's UB to do that in compiler-time Rust) because in compile-time calculations you don't know the exact address of anything! And only these calculations which don't depend on actual addresses of variables should be allowed. Conversion between pointers and integers opens the pandorra box: now either compiler have to track values which originate from pointers or it have to forbid conversion between integers and pointers.

The fact that unsafe Rust have UB even in const evaluation is a bit worrying: why was it done that way? Even const C++ doesn't have UB but Rust does! Scary. And not sure why it's needed: const evaluations are not full language, just something so simple that you can do that during compile-time, why include UB there?

[tczajka]

@VorfeedCanal

It's a bit sad that transmute (or your union trick) can be used to transmute between pointers and integers at compile time (and it's not a compile-time errors like in C++)

Can it? I tried it and I got a lint, and even after disabling that lint, I got a compile error:

Rust Playground

[CAD97]

The blog post is the result of ptr-int transmutes being upgraded from silent UB to a compiler error.

It is a goal that all UB at const time is caught, but it is not computationally feasible to guarantee that all UB is caught. Plus, we're not even sure exactly what the dynamic borrowing rules for pointers are, so we can't exactly guarantee there's no UB there. C++ doesn't have to worry about that.

The biggest case of undiagnosed UB will be access out of bounds of references (e.g. slice::get_unchecked_mut) but which are still in bounds of the underlying allocation. This is a source of UB which is entirely non-existent in C++.

C++ also has the advantage of TBAA and typed memory, whereas Rust's memory is fully untyped and only copies are typed.

I suspect that rustc's const engine does catch every bit of UB that constexpr C++ can run into, and only allows through the "spicy Rust specific UB" resulting from the dynamic borrow rules.