introduce explicitly-sized enum types, deprecate G_TYPE_ENUM
@walters
Submitted by Colin Walters Link to original bug (#686662)
Description
See https://bugzilla.redhat.com/864196 for downstream discussion.
The executive summary is that in for enums in C, the compiler will choose a storage type (unsigned int, long long) based on what the enum contains. For GCC, if the enum's values fit in the range of 0-G_MAXUINT, unsigned int will be chosen. This fits "most" enums. If you have negative numbers, but the range fits into G_MAXINT, you get an int, unsurprisingly.
A case that's not handled at all by G_TYPE_ENUM is if you have > G_MAXINT values. GCC will choose e.g. guint64, but the public enum API is only 32 bit sized.
A corner case here is that enums that fit in G_MAXUINT but not G_MAXINT will fail on some architectures like PPC64, which is the issue linked above.
Now, what we need to do is add types so that library users can explicitly specify the size of the enum. This is going to be tedious and painful; but I suspect most library users will just need to do s/G_TYPE_ENUM/G_TYPE_ENUM_UINT/.
Still do be done for this is an analysis of which modules in GNOME need patching.