repr(C) on an enum accepts discriminants that do not fit into the default C enum size

[RalfJung]

Example:

#[repr(C)]
enum OverflowingEnum {
    A = 1111111111111111111,
}

enum overflowing_enum {
    OVERFLOWING_ENUM_A = 1111111111111111111,
};

Rust currently gives size_of::<OverflowingEnum>() = 8. MSVC gives sizeof(enum overflowing_enum) = 4. Additionally, Rust gives OverflowingEnum::A as usize = 1111111111111111111 and MSVC gives OVERFLOWING_ENUM_A = 734294471.

This should probably be a hard error (forward compatibility lint). The nomicon currently states

repr(C) is equivalent to one of repr(u*) (see the next section) for fieldless enums. The chosen size is the default enum size for the target platform's C application binary interface (ABI).

and the reference currently states

For field-less enums, the C representation has the size and alignment of the default enum size and alignment for the target platform's C ABI.

The nomicon is clearly wrong here: #[repr(c_int)] on the enum would fail to compile (where c_int is the correct primitive) (because of the overflowing literal). I think erroring (forward compatibility linting) and pointing the user to use #[repr(u64)] in this case makes sense.

(Summary by @CAD97)

@CAD97 this should error on all targets, not just MSVC, I assume? What do non-MSVC C compilers do with such an enum?

[RossSmyth]

The standard did not say much about enum width until recently. Specifically the standard called out only int as the one true enum type. Specifically the wording was that the underlying type

must be representable by an int

In reality many compilers just silently expanded the width (Godbolt link to an old Clang from before C23) to accommodate values. So your enum would be fine in reality on GCC, Clang, TCC, and many others (though on Godbolt CompCert & TenDRA reject it with an error). Obviously MSVC accepts it, but then silently truncates it to the one true (pre-C23) enum type.

Plus the new standard text says

For all the integer constant expressions which make up the values of the enumeration constant, there shall be a signed or unsigned integer type (excluding the bit-precise integer types) capable of representing all of the values.

Meaning that as long as the value can fit in a unsigned long long then it should be fine (on a C23 compiler). MSVC has not implemented this, or really much of C23 yet.

There is also this new syntax in C23:

enum Foo : uint64_t {
    A = 1111111111111111111,
};

Which is implemented in GCC and Clang for specifying the underlying type exactly.

[RalfJung]

There is also this new syntax in C23:

I think we have the equivalent of that, via repr(u64).

In reality many compilers just silently expanded the width (Godbolt link to an old Clang from before C23) to accommodate values. So your enum would be fine in reality on GCC, Clang, TCC, and many others (though on Godbolt CompCert & TenDRA reject it with an error). Obviously MSVC accepts it, but then silently truncates it to the one true (pre-C23) enum type.

Thanks for checking!

But the standard also doesn't say that truncation is wrong, or does it?

I guess our options are similar to here. Except for this issue I feel completely fine with just erroring when the discriminant does not fit into the default enum type; that should be very rare and warrants an explicit type annotation in any case...

[RossSmyth]

But the standard also doesn't say that truncation is wrong, or does it?

I would say that C23 does say that is wrong. But pre-C23 silently truncating I would also say is a valid behavior.

So it depends on what we are targeting, the C standard or C compilers. If we say "we target C23" then having 64-bit enums would be valid. If we say "we want to allow any weird C compiler to link with us," then erroring is valid too.

[RalfJung]

I would say that C23 does say that is wrong

Where does it say that? The text you quoted just says that the given discriminant value has to fit some integer type, but it does not say that it has to fit the concrete integer type chosen for the enum.

Ah, but there's more text:

During the processing of each enumeration constant in the enumerator list, the type of the enumeration constant shall be: [...]

The thing is, this says that the different enumeration constants of the same enumeration can have different types! That's not possible in Rust -- so maybe we should indeed reject everything that does not fit into an int.

[workingjubilee]

That wording is fairly irrelevant in actuality as the type has to be stored in a fixed width.

It is much worse than you think, Ralf. There is nothing actually requiring the C compiler to use int. That is, it has always been standard-conformant to use only 8- or 16-bit types even when the type of int is defined to be a 32-bit integer. Thus we have to match the actual compiler behaviors on this one, as we cannot look to the standard for saying anything about ABI, because it doesn't.

[RalfJung]

I seemed to remember that compilers use the smallest type that fits, but the standard seemed fairly clear about using int...

Thus we have to match the actual compiler behaviors on this one, as we cannot look to the standard for saying anything about ABI, because it doesn't.

Okay so what is the actual compiler behavior for GCC, clang, MSVC? Does MSVC always use int or does it use "the smallest that fits, or int, whatever is smaller"? How does signed/unsigned factor in?

[workingjubilee]

It says representable by.
All values of type char or short, by definition, are representable by int.

GCC conceals the arbitrary-selection rule behind the -fshort-enums flag, thus making code incompatible based on compiler flags. Lovely practice, that. Clang thus emulates this.

[workingjubilee]

For some of our targets, they are specified as using -fshort-enums in their ABI, or equivalent, which is why we have the notion of a "minimum C enum width" in enum layout.

[workingjubilee]

I believe the MSVC situation is expressed by https://learn.microsoft.com/en-us/cpp/build/reference/zc-enumtypes?view=msvc-170