#[repr(align(N))] fields not allowed in #[repr(packed(M>=N))] structs

[asahilina]

I tried this code:

use std::sync::atomic::AtomicU32;

#[repr(C, packed(4))]
struct Foo {
    bar: AtomicU32,
}

I expected that #[repr(align(4))] fields, such as AtomicU32, would be allowed inside a #[repr(packed(4))] struct, since the minimum alignment is >= the required alignment.

However, the compiler complains:

error[E0588]: packed type cannot transitively contain a `#[repr(align)]` type

Use case: I have some fixed-layout shared memory structs I need to interact with, which sometimes contain unaligned u64s. I also need to use atomics on other parts of them (hopefully only u32s).

Meta

rustc --version --verbose:

rustc 1.65.0-nightly (34a6cae28 2022-08-09)
binary: rustc
commit-hash: 34a6cae28e7013ff0e640026a8e46f315426829d
commit-date: 2022-08-09
host: x86_64-unknown-linux-gnu
release: 1.65.0-nightly
LLVM version: 14.0.6

[RalfJung]

That entire check is anyway somewhat odd since it is easily circumvented:

use std::sync::atomic::AtomicU32;

#[repr(C, packed(4))]
struct FooT<T> {
    bar: T,
}

type Foo = FooT<AtomicU32>;

fn main() {
    let x: Foo = Foo { bar: AtomicU32::new(0) };
}

[koverstreet]

So this affects bcachefs - it's a blocker for using Rust more extensively there.

In C, specifying packed and aligned will round up the size of the type to the alignment specified, so without this fixed it means we can't generate types in Rust that match the C types for our on disk data structures.

[RalfJung]

In C, specifying packed and aligned will round up the size of the type to the alignment specified,

That's not universally true, GCC and MSVC have different behavior. See the discussion here. So accepting this code in Rust would be a major interop footgun.

[RalfJung]

To make progress on this, we need a concrete proposal for what the exact behavior of align(N) fields in packed structs should be, taking into account this problem and also the fact that some code may already exist on stable that could change behavior if we adjust the layout. The comment here could be a good starting point for a proposed solution -- making the resulting layout depend on the target triple (windows-gnu vs windows-msvc).

So, if this is a blocker for someone, I suggest looking into sketching a pre-RFC. :)

[koverstreet]

No, making it depend on the target triple would not be a good solution - this is important for on the wire formats, the behavior has to be explicitly controllable. Just make it another #[repr] thing.

[koverstreet]

And this does need to be fixed; it's a blocker for C FFI. We've worked around it for now in bindgen for bcachefs, but that was a hack and we've been waiting on compiler guys to fix this properly.

[RalfJung]

You cannot have both, use it for C FFI and have it fixed independent of the target triple. That's the entire point. So pick one.

[RalfJung]

And given that the repr is called C, and a stable platform-independent repr is in the works (#105586), it seems to me that the primary role of repr(C) is to match the dominant C compiler of the given target. If that means it differs between targets, then that's unfortunate -- but it can't really be helped.

[koverstreet]

"C FFI" is a wider issue than just communicating with code linked in to the same binary. If an on disk format is defined in C, it's a bug if we cannot specify the correct representation.

The existing silent different in behaviour between gcc and Microsoft is a bug, and it's perfectly straightforward to fix it here, but you're insisting that it 'can't be helped'. No, you're the one who's got this wrong.

"Match the host" should be one option, but it should be specified, per data type, not silently guessed at.