On Sunday, 17 September 2017 at 17:06:10 UTC, bitwise wrote:
I don't really see a way to deal with this aside from branching
the entire library and inserting something like
'FT_SIZE_REQUEST_TYPE__FORCE_INT = 0xFFFFFFFF' into every enum
incase the devs used it in a struct.
Just put the burden on the users then. It's implementation
defined, so they are in position to figure it out...
for example, gcc: "Normally, the type is unsigned int if there
are no negative values in the enumeration, otherwise int. If
-fshort-enums is specified, then if there are negative values it
is the first of signed char, short and int that can represent all
the values, otherwise it is the first of unsigned char, unsigned
short and unsigned int that can represent all the values. On some
targets, -fshort-enums is the default; this is determined by the
ABI."
https://gcc.gnu.org/onlinedocs/gcc-6.4.0/gcc/Structures-unions-enumerations-and-bit-fields-implementation.html#Structures-unions-enumerations-and-bit-fields-implementation
msvc++: "A variable declared as enum is an int."
https://docs.microsoft.com/en-us/cpp/c-language/enum-type
It's probably pretty safe to assume it's an int; people who play
tricks with "-fshort-enums" deserve what's coming to them :)
