### Author:  [@retep998](https://internals.rust-lang.org/u/retep998)
#### Post date: [October 8, 2015, 12:22am UTC](https://internals.rust-lang.org/t/c-style-enums-in-ffi-and-a-proposal-to-lump-in-with-unions/2744/5 "2015-10-08T00:22:42Z")
```rust
#[repr(C)]
enum C {
A = -1,
B = 0x80000000,
}
```
That prints a size of 8. Enums in Windows API will sometimes have shenanigans with either negative discriminants or discriminants that are greater than the range provided by an i32. In C/C++ land it is always 32-bit, and if you try to put something greater than a u32 can provide it errors, but in Rust it just increases the size and compiles fine.
---
### Author:  [@mzabaluev](https://internals.rust-lang.org/u/mzabaluev)
#### Post date: [October 8, 2015, 6:23am UTC](https://internals.rust-lang.org/t/c-style-enums-in-ffi-and-a-proposal-to-lump-in-with-unions/2744/6 "2015-10-08T06:23:46Z")
> [@retep998](#):
>
> In C/C++ land it is always 32-bit
By the standard, one should not expect to be able to use discriminants that cannot be represented by `int`. So I guess what to do with discriminants that fit in `unsigned int`, but not `int`, is implementation-dependent.
What does MSVC make out of:
```c
#include
typedef enum {
A = 0x80000000,
B = -0x80000000
} C;
int main() {
C val = A;
printf("sizeof: %u\n", (unsigned)sizeof(val));
printf("it %s wrap around!\n", (val == B)? "does" : "does not");
return 0;
}
```
With GCC on `x86_64-redhat-linux`, it does wrap around. Curiously, it takes option `-Wpedantic` for the compiler to start complaining; even `-Wall -Wextra -std=c11` will not result in any warning. Yeah, we all know `-Wall` is a lie...
> [@retep998](#):
>
> In C/C++ land it is always 32-bit, and if you try to put something greater than a u32 can provide it errors, but in Rust it just increases the size and compiles fine.
There is an issue here, indeed. Rust should be compatible, quirk-for-quirk, with the behavior of the de-facto main C compiler on the target.
---
### Author:  [@mzabaluev](https://internals.rust-lang.org/u/mzabaluev)
#### Post date: [October 8, 2015, 6:48am UTC](https://internals.rust-lang.org/t/c-style-enums-in-ffi-and-a-proposal-to-lump-in-with-unions/2744/7 "2015-10-08T06:48:21Z")
A couple more discoveries.
This is 64-bit wide accordingly to GCC:
```rust
typedef enum {
A = 0x80000000LL,
B = -0x80000000LL
} C;
```
This doesn’t compile in today’s Rust:
```rust
#[repr(C)]
enum C {
A = -1,
B = 0x80000000u32,
}
```
So, it appears that GCC uses the discriminants’ types (including implicit value-based coercions) to decide on the size of the enum, while Rust coerces all values to `isize` and tries to work back from there.
---
### Author:  [@mzabaluev](https://internals.rust-lang.org/u/mzabaluev)
#### Post date: [October 8, 2015, 7:50am UTC](https://internals.rust-lang.org/t/c-style-enums-in-ffi-and-a-proposal-to-lump-in-with-unions/2744/8 "2015-10-08T07:50:32Z")
> [@mzabaluev](#):
>
> C uses the discriminants' types (including implicit value-based coercions)
It's not just the value, the literal's numeric base also figures: [http://en.cppreference.com/w/c/language/integer\_constant](http://en.cppreference.com/w/c/language/integer_constant)
---
### Author:  [@nikomatsakis](https://internals.rust-lang.org/u/nikomatsakis)
#### Post date: [October 8, 2015, 10:44pm UTC](https://internals.rust-lang.org/t/c-style-enums-in-ffi-and-a-proposal-to-lump-in-with-unions/2744/9 "2015-10-08T22:44:13Z")
> [@mzabaluev](#):
>
> On the other hand, if #[repr(C)] on x86\_64-pc-windows-msvc ends up being something completely different than what the C compiler uses by default, there is a problem.
Huh. I'm trying to remember the details here, but certainly our intention was that #[repr(C)] would match the "main C compiler", to the extent that this is possible. I sort of remember that we decided to just use `i32` unless explicitly specified, as part of the overflow checking work, but maybe I have it wrong. @pnkfelix do you remember?
---
### Author:  [@mzabaluev](https://internals.rust-lang.org/u/mzabaluev)
#### Post date: [October 9, 2015, 7:17am UTC](https://internals.rust-lang.org/t/c-style-enums-in-ffi-and-a-proposal-to-lump-in-with-unions/2744/10 "2015-10-09T07:17:15Z")
I have submitted my findings as a [Github issue](https://github.com/rust-lang/rust/issues/28925).
---
### Author:  [@pnkfelix](https://internals.rust-lang.org/u/pnkfelix)
#### Post date: [October 13, 2015, 2:09pm UTC](https://internals.rust-lang.org/t/c-style-enums-in-ffi-and-a-proposal-to-lump-in-with-unions/2744/11 "2015-10-13T14:09:27Z")
(no I don’t remember the discussion here.)
---
### Author:  [@jld](https://internals.rust-lang.org/u/jld)
#### Post date: [November 23, 2017, 4:07am UTC](https://internals.rust-lang.org/t/c-style-enums-in-ffi-and-a-proposal-to-lump-in-with-unions/2744/12 "2017-11-23T04:07:23Z")
As I recall, it was meant to match the target’s C ABI, and git agrees with my memory: the exact words I used were “match the target’s C ABI for the equivalent C enum”. I remember I spent some time looking at ABI specs for the targets that were supported at the time, but I missed that Windows has a _maximum_ size. So that’s a bug, in my opinion.
Also, there’s probably at least one target that’s been added in the past 4 years where the `i32` default is wrong. (Originally there was no default, but the target architecture was changed from an `enum` to a string at some point.)
But trying to match C exactly is… difficult, as the examples in the above-linked GitHub issue demonstrate; this raises the question of whether “the equivalent C enum” is a well-defined concept.
And there’s the problem where C allows values that are impossible for the Rust `enum`. This raises the possibility that `#[repr(C)]` was never the right way to do C `enum` FFI. I don’t remember whether we just completely overlooked it, maybe because FFI usage was mostly Rust→C rather than C→Rust and being unable to generate those values wasn’t as bad as not being able to handle them, or if we noticed it and meant to do something about it at some point and nobody ever did, or what.
As for what to do about it: it would be nice to have something in the base language, or even a crate like `libc`, rather than requiring bindgen and/or winding up with code assuming `i32` and breaking on uncommon platforms.
---
### Author:  [@system](https://internals.rust-lang.org/u/system)
#### Post date: [March 25, 2019, 8:25am UTC](https://internals.rust-lang.org/t/c-style-enums-in-ffi-and-a-proposal-to-lump-in-with-unions/2744/13 "2019-03-25T08:25:17Z")
This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.