Using implicit padding on C FFI prevents Rust from writing / copying those bits

[gnzlbg]

@sunfishcode pointed out here (#1321 (comment)) that when we use explicit padding on C FFI:

struct Foo {
   _pad: u32;
  pub field: u16
}

Rust will insert copies, etc. for the padding bits, and when users write code like:

let foo = MaybeUninit::<Foo>::zeroed().assume_init();

those fields will be zeroed.

However, if we were to use

#[repr(align(4))] 
struct Foo {
    pub field: u16,
}

instead, this would not be the case.

We don't have that many types using repr(align) and repr(packed) explicitly, so we should manually check those against the C headers, and verify that they only use these attributes when C does so as well.

[gnzlbg]

Either way, one way to make Rust code "forward-compatible" with fixes that would require adding / removing private fields would be to add a private ZST to the type. That would prevent people from assuming that all field types will always be public, which is what leads to breaking changes when it comes to padding / alignment.

[tgross35]

#[non_exhaustive] would work here too and probably be more clear #4080