[HarfBuzz] enum issue

[Richard Wordingham]

On Tue, 04 Mar 2014 10:47:47 -0800
Behdad Esfahbod <behdad at behdad.org> 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.