It's to ensure that our types are fixed-size instead of being compiler-dependent. By default, enum in C is an int, and the size of an int 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 uint32_t or uint16_t 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 int space. This is fine so long as your machine's int is of a sufficient size to represent all of our values.
At this stage that's likely mostly true with exception of one:
SpectreCounterLast = UINT32_MAX
With the enum an int, this will define a value that resolves to -1, rather than the expected upper bound of 4294967295. However, internally it should be fine since this value is always assigned to a variable typed SpectreCounter, which will re-interpret the value as a uint32_t, restoring the original value of 4294967295. Just make note that if you should use this value directly from Rust that you also re-interpret it as a SpectreCounter 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.
