Why is it not allowed to cast a &mut Pod or &mut [u8] to a &mut AnyBitPattern ?

[agausmann]

I'm interested in this for a specific scenario I'm working on - reinterpreting a byte buffer into a mutably referenced struct that may contain padding. Specifically, I'm trying to make (and automatically generate) more ergonomic bindings for WGSL uniform buffers, where the layout has certain alignment requirements and so they often have padding.

Traditionally, I've done this just with Pod, and added extra padding on the Rust side explicitly using byte arrays. AnyBitPattern seemed appealing for this use case at first glance, but then I noticed that cast_mut and from_bytes_mut are not relaxed in the same way that cast and cast_ref were with AnyBitPattern. Based on this, I'd guess that allowing cast_mut and from_bytes_mut would have been unsound, and I am curious why, exactly?

---

My guess, after thinking about it for some time: if I try to do *from_bytes_mut::<SomeAnyBitPatternType>(&mut some_bytes) = some_val, that might copy the uninitialized padding of some_val into some_bytes. So even though the bytes were initialized, they could have garbage written to them?

[Lokathor]

reinterpreting a byte buffer into a mutably referenced struct that may contain padding

This specific pattern, of going from all initialized to a view where not all are initialized, has a slight hiccup. If it's an immutable view that's no problem, you're only looking, so it's okay to not look at some of the bytes.

The mutable case is basically as you guessed: If it's a mutable view than a write will actually deinitialize some bytes, and then when you "undo" the &mut HasPadding to have just &mut [u8] again, there's some uninit memory in your byte slice.