[ft-devel] Outline n_points are int16 so overflow is possible because missing check

[Boris Letocha]

Hi,

I want to report bug in handling huge (in number of points) glyphs. (I can 
provide such generated font on request, don't sending to list as it has 1.2MB)
If you create Type1 (could apply also to different types) font with more than 
32767 points in one glyph outline->n_points will wrap around 16bits to -32768 
in t1_builder_add_point and start corrupting memory. IMHO check for this 
limitation needs to be added to FT_GlyphLoader_CheckPoints function. But where 
could be another problem with local overflow in:
#define FT_GLYPHLOADER_CHECK_P( _loader, _count )                    \
   ( (_count) == 0 || (int)((_loader)->base.outline.n_points    +    \
                            (_loader)->current.outline.n_points +    \
                            (_count)) <= (int)(_loader)->max_points )
In some cases sum could be also done in shorts then widened to int and not 
detecting overflow, so it will not call FT_GlyphLoader_CheckPoints.

Maybe better solution would be completely remove this limitation by changing 
all these shorts to ints and actually increase speed on most platforms 
(unfortunately - this would need to be done on many places look at contours 
array).

Regards,

Boris Letocha