On Tue, 04 Mar 2014 10:47:47 -0800 Behdad Esfahbod <[email protected]> wrote:
> That negates the reason we added that line to begin with, which was > to ensure all hb_tag_t's fit in hb_script_t. How about: > > _HB_SCRIPT_DUMMY1 = 0x7FFFFFFF, > _HB_SCRIPT_DUMMY2 > > The idea being that DUMMY2 gets value of 0x80000000, ensuring that > hb_script_t can represent up to 0xFFFFFFFF. But the value of DUMMY2 is not a value of (32-bit) int! We should get the same compiler warning, and seem to be worse off than having the original value of HB_TAG_MAX. C99 does not allow one to force an enumeration type to be implemented as unsigned int. With 32-bit int, there is no guarantee that there is an enumeration type in C that can hold all values of hb_tag_t. A possible solution is #ifdef __cplusplus _HB_SCRIPT_MAX_VALUE = HB_TAG_MAX #else HB_SCRIPT_BIG_POS = 0x7FFFFFFF, HB_SCRIPT_NEG = -1 #endif (Any identifier beginning _H is reserved in C99.) This forces hb_script_t to be at least 32 bits wide. If int is 32 bits, then the compiler can choose (unsigned int) for C++ and (signed int) for C, which is the best we can do for consistency. I have to confess that I don't know how to make an enumeration type exactly 32 bits wide if the type int is wider. Making the C and C++ enumeration types as wide as int can be done using UINT_MAX and INT_MAX rather than HB_TAG_MAX and 0x7FFFFFFF. Richard. _______________________________________________ HarfBuzz mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/harfbuzz
