Each enumerated type shall be compatible with char, a signed integer type, or an unsigned integer type. The choice of type is implementation-defined,110) but shall be capable of representing the values of all the members of the enumeration. The enumerated type is incomplete until after the } that terminates the list of enumerator declarations.
with the footnote:
110) An implementation may delay the choice of which integer type until all enumeration constants have been seen.
Thus it's not possible to infer without further platform ABI, C compiler and library version information how the enum type will be represented in terms of storage. Further, given the footnote, the size of the underlying storage for the enum may change over time if additional members are added to the enum. These facts in turn makes it hard to e,g, create reliable FFI bindings for the library. IMO use of enums in public APIs should be avoided, and use of explicitly sized types and macros for named constants should be preferred.
WG14/N1256 (C99 draft standard) 6.7.2.2 paragraph 4 states:
with the footnote:
Thus it's not possible to infer without further platform ABI, C compiler and library version information how the enum type will be represented in terms of storage. Further, given the footnote, the size of the underlying storage for the enum may change over time if additional members are added to the enum. These facts in turn makes it hard to e,g, create reliable FFI bindings for the library. IMO use of enums in public APIs should be avoided, and use of explicitly sized types and macros for named constants should be preferred.