It's to ensure that our types are fixed-size instead of being compiler-dependent. By default, Login to see the code in C is an Login to see the code, and the size of an Login to see the code type is machine-dependent (eg. many 16-bit systems use a 2-byte int, most 32/64-bit systems use a 4-byte int).
Forcing our types to a fixed Login to see the code or Login to see the code depending on the type ensures that the types are predictable and their range of expected values are fully supported across architectures and into the future.
Under your change, the named types will still be the fixed size they're expected to be, but the actual enum values will become limited to the Login to see the code space. This is fine so long as your machine's Login to see the code is of a sufficient size to represent all of our values.
At this stage that's likely mostly true with exception of one:
Login to see the code
With the Login to see the code an Login to see the code, this will define a value that resolves to Login to see the code, rather than the expected upper bound of Login to see the code. However, internally it should be fine since this value is always assigned to a variable typed Login to see the code, which will re-interpret the value as a Login to see the code, restoring the original value of Login to see the code. Just make note that if you should use this value directly from Rust that you also re-interpret it as a Login to see the code type or 32-bit unsigned integer.
Again, this is why this should be a local change and deemed a "work-around" until the Rust community can offer clarity on why it's unable to import the original C types without conflict.
