Explicitly cast to uin16_t to avoid an invalid implicit type narrowing.

Explicitly cast to uin16_t to avoid an invalid implicit type narrowing.

This was causing a build failure on OS X for us:

SkOTTable_head.h:124:72: error: non-type template argument evaluates to -2, which cannot be narrowed to type 'uint16_t' (aka 'unsigned short') [-Wc++11-narrowing]

Committed: https://code.google.com/p/skia/source/detail?r=5290

[reed1, 2012-08-27 12:56:36]

I'm OK with this change, but I will defer to Ben.

Side note:

    static_cast<SK_OT_SHORT>(SkTEndian_SwapBE16((uint16_t)-1))

That's a long line. Do we really need static_cast<...> as well? My read of
SkTEndian_SwapBE16 is that it is defined to return uint16_t.

[bungeman, 2012-08-27 14:18:19]

Since this was the conversion that was implicitly happening before anyway, lgtm.
Mike does have a point that SK_OT_SHORT should be uint16_t instead of int16_t
though; I'll make that change later.

[gw280, 2012-08-27 15:11:50]

On 2012/08/27 14:18:19, bungeman wrote:
> Since this was the conversion that was implicitly happening before anyway,
lgtm.
> Mike does have a point that SK_OT_SHORT should be uint16_t instead of int16_t
> though; I'll make that change later.

Would it perhaps be more readable to explicitly use 0xFFFF and 0xFFFE instead?

[bungeman, 2012-08-27 15:39:43]

On 2012/08/27 15:11:50, gwright wrote:
> On 2012/08/27 14:18:19, bungeman wrote:
> > Since this was the conversion that was implicitly happening before anyway,
> lgtm.
> > Mike does have a point that SK_OT_SHORT should be uint16_t instead of
int16_t
> > though; I'll make that change later.
> 
> Would it perhaps be more readable to explicitly use 0xFFFF and 0xFFFE instead?

More readable? No, the spec actually says this value is '-1' or '-2';
obfuscating further isn't going to make this clearer. This cast is just to
satisfy a C++11 warning in any event.