[HarfBuzz] enum issue

Richard Wordingham richard.wordingham at ntlworld.com
Tue Mar 4 14:29:03 PST 2014

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:
> 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

(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.


More information about the HarfBuzz mailing list