`IsZero` for raw pointers is unsound

[joboet]

The IsZero trait is used to specialize vec![val; n] to use allocate_zeroed when the val being duplicated is zero. But in the case of raw pointers, this is not correct as the bytes returned by allocate_zeroed do not have the same provenance as val. Thus, the following code triggers undefined behaviour (playground) when it shouldn't

let ptr = std::ptr::from_ref(&42);
let zero = ptr.with_addr(0);
let roundtripped = vec![zero; 1].pop().unwrap();
let new = roundtripped.with_addr(ptr.addr());
unsafe { new.read() };

[saethlin]

I removed the strict-provenance label because this can be reproduced without using the strict provenance APIs:

fn main() {
    let ptr = std::ptr::from_ref(&42u8);
    let zero = ptr.wrapping_sub(ptr as usize);
    let roundtripped = vec![zero; 1].pop().unwrap();
    let new = roundtripped.wrapping_add(ptr as usize);
    unsafe { new.read() };
}

[scottmcm]

Pondering: We have IsZero for Option<&T> and Option<Box<T>> as well.

I guess those are fine because the None for those isn't allowed to carry provenance, even though it's guaranteed to "be" a null pointer?

[lolbinarycat]

One difference is that 0 may actually be a meaningful address for a raw pointer, as is the case with interrupt vectors on some platforms.

[hanna-kruppe]

Rust does not support that: a null pointer is never valid and the null pointer has address zero. If there’s something at address zero on the platform you target, you have to access it with inline assembly. See previous discussion at rust-lang/unsafe-code-guidelines#29