> +/// If a struct implements this trait, then it is okay to copy it byte-for-byte > +/// to userspace. This means that it should not have any padding, as padding > +/// bytes are uninitialized. Reading uninitialized memory is not just undefined > +/// behavior, it may even lead to leaking sensitive information on the stack to > +/// userspace. This feels a bit too restrictive to me. Isn't it okay to copy types with padding if it is ensured that the padding is always initialized? I recall that in C one occasionally does a `memset` for structs that are copied to user space. I imagine that one could have a Rust abstraction/macro that makes it easy to define custom types that can always guarantee that all padding bytes are initialized. Such types would then qualify for being copied to user space if all field do so as well. This could be a significant quality-of-life improvement for drivers as it can be tedious to define struct without padding. - Best Valentin