Why exactly can't you use this crate with types with padding bytes?

[laptou]

I would like to use this crate with wgpu shaders, however, the WGSL standard imposes a pesky stipulation that uniform structs must be 16-byte aligned. I would like to solve this by simply creating matching structures in Rust, marking them #[repr(C, align(16))], and calling it a day, and indeed when I convert these structs into bytes myself using std::mem::transmute it seems to work. Why is presence of padding bytes incompatible with the bit-blit operation of Pod?

[Lokathor]

Since a type's size is always a multiple of its alignment, then if the value is aligned to 16 but the fields are only a total of 12 bytes (say a vec3), then there will be 4 bytes of padding inserted to bring the type's size to a multiple of 16 (in this case 16*1). If you transmute that value into a byte array ([u8; 16]) array, then the first 12 bytes would be initialized and the last 4 bytes would be unitialized. In Rust you aren't allowed to convert uninitialized memory into normal data types (you have to use MaybeUninit).

[laptou]

Got it. But if that uninitialized memory is in the padding bytes, which I can't access using safe Rust anyway, then why does it matter?

[Lokathor]

Well the bytemuck crate lets a person do a lot of things that safe Rust doesn't normally allow (such as bit-casting values, and casting slice values) by internally using unsafe code. The unsafe code is correct only as long as it follows various rules, including the rule about uninit memory not being converted into normal values.

If the Pod trait didn't have a rule about uninit memory being disallowed then all of the functions of bytemuck could be tricked into performing UB.