LGLYPH_SET_CODE

LGLYPH_SET_CODE

[Eli Zaretskii]

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.

Re: LGLYPH_SET_CODE

[Kenichi Handa]

In article <u1w081a7p.fsf@gnu.org>, Eli Zaretskii <eliz@gnu.org> 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
handa@ni.aist.go.jp

Re: LGLYPH_SET_CODE

[Jason Rumney]

Kenichi Handa wrote:

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

WORD is defined as below in the Windows system headers:

typedef unsigned short WORD;

So I think it is safe.

Re: LGLYPH_SET_CODE

[Richard M. Stallman]

    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.

At least there should be a loud comment next to the definition,
"Make sure VAL is not negative!"

Re: LGLYPH_SET_CODE

[Kenichi Handa]

In article <E1KZDhI-0001fW-F2@fencepost.gnu.org>, "Richard M. Stallman" <rms@gnu.org> writes:

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

> At least there should be a loud comment next to the
> definition, "Make sure VAL is not negative!"

Ok, done.

---
Kenichi Handa
handa@ni.aist.go.jp