The compiler should error when trying to transmute pointer values with incompatible alignment

[hkBst]

I tried this code:

struct Foo {
    a: i32,
    b: i32,
}

fn main() {
    unsafe {
        let mut array: [u8; 1024] = [1; 1024];
        let foo = std::mem::transmute::<&mut u8, &mut Foo>(&mut array[0]);
        foo.a += 1;
    }
}

I expected to see this happen: the compiler complains about the alignment of the array not being good enough for the struct Foo

Instead, this happened: the compiler did not complain

Meta

rustc --version --verbose:

1.59.0 from the playground

This issue was noticed by the creator of Zig in this blog post: https://andrewkelley.me/post/unsafe-zig-safer-than-unsafe-rust.html.

[leonardo-m]

Yes, here the Zig type system has static guarantee stronger than Rust ones because it (optionally?) keeps track of alignments.

[nagisa]

Worth noting that this is largely just Invalid Code for Reasons, among Some Others, but presuming it didn't really invoke a nicely blooming bouquet of UB, the only way to tell a transmute is possibly producing an underaligned reference would be by tracking alignment of an allocation as part of its Provenance.

In particular one could imagine code like this being considered valid enough:

transmute::<&mut u8, &mut T>(transmute::<&mut T, &mut u8>(v))

an “equivalent” of which in Zig appears to compile down to runtime tests by default. Not necessarily a bad strategy, but also not something transmute can do, given its contract.