Re: LGLYPH_SET_CODE

[Kenichi Handa]

In article <address@hidden>, Eli Zaretskii <address@hidden> writes:

> Can the second argument to this macro be negative?  If so,
> the current definition:

>    #define LGLYPH_SET_CODE(g, val)                                    \
>      do {                                                             \
>       if (val == FONT_INVALID_CODE)                                   \
>         ASET ((g), LGLYPH_IX_CODE, Qnil);                             \
>       else if ((EMACS_INT)val > MOST_POSITIVE_FIXNUM)                 \
>         ASET ((g), LGLYPH_IX_CODE, Fcons (make_number ((val) >> 16),  \
>                                           make_number ((val) & 0xFFFF)));\
>       else                                                            \
>         ASET ((g), LGLYPH_IX_CODE, make_number (val));                \
>      } while (0)

> does not handle such values correctly, because their
> absolute value could be large enough to overflow an
> EMACS_INT.  If negative values are possible, we should use
> FIXNUM_OVERFLOW_P instead of a comparison with
> MOST_POSITIVE_FIXNUM.

It is intended that VAL is not negative.  That macro is
called at four places, and except for one place, it is
assured that VAL is never negative.  The exception is in
uniscribe_shape of w32uniscribe.c:

                  LGLYPH_SET_CODE (lglyph, glyphs[j]);

The type of glyphs[j] is "WORD" and I don't know if it's
unsigned or not, I don't know if ScriptShape set a negative
value in it or not.  Anyway, if it's possible that glyphs[j]
becomes negative, that function should be modified not to
call LGLYPH_SET_CODE with negative VAL.

---
Kenichi Handa
address@hidden