repr(C, align) is unsound on enums

[mahkoh]

repr(align) on enums is implemented as described in the reference:

The align modifier can also be applied on an enum. When it is, the effect on the enum's alignment is the same as if the enum was wrapped in a newtype struct with the same align modifier.

But this is not how aligned enums work in Clang, GCC, and MSVC

• GCC ignores alignment requests on enums.
• Clang sets the alignment to the requested alignment even if this decreases the alignment. The size is unaffected.
• MSVC increases the alignment to the requested alignment. The size is unaffected.

[RalfJung]

You used the term "unsound", which in Rust means "can cause UB without using unsafe code". I do not understand from your description how unsoundness can arise here. Could you go into more detail about that?

[RalfJung]

So the expected behavior here is that #[repr(C, align(n))] on an enum yields a layout that's the same as "an aligned enum in Clang, GCC, and MSVC" (I don't know the syntax for that)? And due to this bug, this is not in general the case? Would be good if you could give a concrete example of a type that you think should be laid out differently. I can't say from the RFC if this was considered before.

Clang sets the alignment to the requested alignment even if this decreases the alignment.

Is that specific to enums, or does this also lead to differences with #[repr(C, align(n))] structs?

The size is unaffected.

Can't this lead to types whose alignment is larger than their size? What happens in C when you put these into an array? In Rust, the size must always be a multiple of the alignment, so leaving the size unaffected is, in general, impossible.

[RalfJung]

Cc #81996 -- the discussion about the purpose of repr(C) over there also seems relevant here.

[RalfJung]

Also see this Zulip discussion.

[RalfJung]

@hyd-dev points out that clang's behavior here seems really buggy... Enum an Enum[1] have different sizes!

[ojeda]

It happens with a simple overaligned integer too:

typedef int __attribute__((aligned(128))) T;
int f() { return sizeof(T); }
int g() { return sizeof(T[1]); }

But that isn't quite portable since GCC does not allow such arrays even if of length 1 (which seems reasonable to me). So GCC allowing it for enums seems like a bug more than anything else, which is probably due to what @mahkoh mentions: it simply discards the alignment (which should fail to compile, in my view).

Thus whatever Clang is doing for arrays of overaligned aligned ints/enums should not matter much :-)

[mahkoh]

You used the term "unsound", which in Rust means "can cause UB without using unsafe code".

I don't agree with this definition. What would you call unsafe { *(1 as *mut u8) } if not "unsound"?

Is that specific to enums, or does this also lead to differences with #[repr(C, align(n))] structs?

This behavior is specific to typedes and enums. But not to enums in GCC. Since repr cannot be applied to type, this issue is only about enums.

Can't this lead to types whose alignment is larger than their size? What happens in C when you put these into an array?

The elements in the array start at multiples of sizeof(T), the overall size of the array is rounded up to _Alignof(T).

@hyd-dev points out that clang's behavior here seems really buggy... Enum an Enum[1] have different sizes!

I do not see why this would be considered a bug. Since clang contains explicit code to round the size of the array up to its alignment, and since such code only has an effect when the size of the element type is not a multiple of the alignment, this behavior is most likely intentional.

But that isn't quite portable since GCC does not allow such arrays even if of size 1 (which seems reasonable to me).

That's incorrect.

typedef char Char[3] __attribute__((aligned(2)));

struct X {
	Char c[3];
} x;

int main(void) {
	_Static_assert(sizeof(x.c) == 10, "");
	_Static_assert(__builtin_offsetof(struct X, c[1]) == 3, "");
	_Static_assert(_Alignof(Char) == 2, "");
}

[RalfJung]

What would you call unsafe { *(1 as *mut u8) } if not "unsound"?

It is called "Undefined Behavior". See the UCG glossary.

Soundness as a concept only makes sense as the property of a type system or a safe API.

[CAD97]

Specifically: unsafe { *(1 as *mut u8) } in a safe context is unsound code, in that it causes UB when run.

#[repr(C, align)] is not by itself unsound (per the UCG definitions), as the presence of the attribute by itself does not cause any UB. Rather, the assumption that #[repr(C)] has the same result as #pragma align in C, and writing unsafe code based on that assumption, produces unsound code.

So, if #[repr(C, align)] is intended to match the behavior of a #pragma aligned enum in the system's ABI, then the incorrectness is a soundness issue (results in unsound code), but not in-and-of-itself unsound.

_{This is my interpretation of the glossary, and not normative.}

Given that #[repr(C)] on enums is defined even for non-C-like enums, and #[repr(C, ?)] for enums was defined by RFC, changing this to match the system ABI's #pragma align (if that's even a well-defined concept) is probably harder than arguing the other issue. You'll also have to explain why #[repr(C, align)] behaves differently for C-like enums and ADT-like enums; I highly doubt changing it to underalign types on some platforms is a good idea without the platform-C compatibility argument.

#[repr(C)] on enums was defined to be "a reasonably C-compatible layout" by the RFC, not specifically what platform-C does. I can be convinced that #[repr(C)] ZST types should be made not-ZST on platforms where that's the behavior of the system ABI, but making the same argument for Rust enums (which have very different semantics from C enums, e.g. Rust doesn't ever allow creating an enum value from an unnamed discriminant, even with #[repr(C)]) is going to be much harder.

Also, this has an additional issue: you say that the Clang behavior of generating a type with a larger alignment than size is intended. Rust currently requires that size is a multiple of alignment, and a lot of code is written assuming this to be the case. I do not believe it is possible for Rust to ever support a type with a size less than its alignment.

[mahkoh]

There are multiple types of alignments: https://github.com/mahkoh/repr-c/blob/2bbc981d874e5769637edc16dc27ed20c794ed0b/repc/impl/src/layout.rs#L71-L95

[CAD97]

Maybe in C (implementations), but not in Rust. In Rust, types only have the singular alignment, are always aligned to at least that alignment, and always have a size that is a multiple of that alignment. https://doc.rust-lang.org/src/core/alloc/layout.rs.html#26-38

[mahkoh]

https://doc.rust-lang.org/nightly/core/intrinsics/fn.min_align_of.html
https://doc.rust-lang.org/nightly/core/intrinsics/fn.pref_align_of.html

[CAD97]

And pref_align_of is never used anywhere in the rust-lang/rust repository: https://github.com/rust-lang/rust/search?q=pref_align_of

[mahkoh]

And?

[CAD97]

You pointed out that the function exists (assumedly to refute that Rust only has one concept of alignment). My point is that pointing at an unused intrinsic that's been around since 2012 and is barely not a candidate for cleanup/removal (because it has a whole one (1) test) is not really a counterargument.