The behavior of returning a value of a type containing an explicit padding field from C into Rust might be undefined

[gnzlbg]

libc uses integers and aggregates of integers for explicit padding byte fields. When these fields are returned from C, they might be uninitialized. We currently do not have any wording in the spec saying that an uninitialized integer is not instant undefined behavior, and there are proposals that define them to both be ok, and to actually be instant undefined behavior.

These padding fields should use MaybeUninit<INT> instead.

The right way to actually fix this issue is to actually remove these padding fields. They only exist because repr(align(N)), repr(packed(N)), unions, etc. did not exist when these types were added. For toolchains that actually support MaybeUninit, we can actually do better and don't use any kind of padding fields at all. For toolchains that do not support repr(align(N)), repr(packed(N)), unions, etc. MaybeUninit does not exist and cannot be actually implemented in Rust, so there is nothing we can do.

For C types using FAM, there is no way to avoid undefined behavior in Rust today, so we have to use explicit padding fields.

Removing these fields or changing their type are major breaking changes when these fields are public. Most of these fields are private, but some of them aren't.

Rust currently does not exploit this potential undefined behavior for anything, and for most targets, it cannot actually exploit it since the C library is dynamically linked or linked without cross-lang-lto. If we start using cross-lang-lto, e.g., when statically-linking musl, this could become an issue in the future.