`as_bytes` is unsound

[andrewhickman]

It is unsafe to view an arbitrary type as bytes because it might contain uninitialized padding bytes.

zerocopy solves this with a derive macro but it is a bit limited (it doesn't work with generics, and implementing it manually is discouraged)

Unfortunately many types in this crate have padding, so there isn't really a great alternative 😕

[zakarumych]

Could you please provide a quote supporting that reading bytes from padding is invalid?

[andrewhickman]

This seems to be the best official definition for padding at present https://github.com/rust-lang/unsafe-code-guidelines/blob/master/reference/src/glossary.md#padding

Copying Pad ignores the source byte, and writes any value to the target byte. Or, equivalently (in terms of Abstract Machine behavior), copying Pad marks the target byte as uninitialized.

So I think if you do

let padding_byte: u8 = as_bytes(my_struct)[padding_index);
println!("{}", padding_byte);

padding_byte would be considered uninitialized.

[zakarumych]

I guess you're right. It can only return *const [u8] in this case.
Other alternative is to fill padding with fields and initialize them.

[zakarumych]

Oh, another option would be returning &[MaybeUninit<u8>]

[LPGhatguy]

I think I found a clever solution to this problem involving generating const functions that compute alignment padding between each member. Imagine creating a derive macro that generates code like this: https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=b309095885a8d96c60f4681727063a04

It's made a lot simpler by the expanded const fn support in Rust 1.46.0, which I think makes things like this a lot more plausible.

[LPGhatguy]

I took a stab at implementing this as part of a new crate. It might serve as good inspiration. Instead of using ZSTs aligned with #[repr(align(N))], it uses the const fn trick I demoed above: https://github.com/LPGhatguy/crevice