> What is the Freetype policy and/or goals with regard to integer
> overflows?
Overflows should be avoided. If you need an exact bit width, use
FT_Int{16,32}. 64bit variables are nowhere used except in code
guarded with FT_LONG64 (however, the code should be written so that it
works with FT_Int having a width of 64 bits). If you really need
64bit intermediate precision, you should use FT_MulDiv and friends.
> How practical are the large sizes that push outline dimensions
> beyond 16 bits, or pixel size of 1024?
They can happen. At 600dpi, a glyph with a height of two inches (as
might happen in a newspaper headline) has a pixel size of 1200. Given
that recent screens for tablets have resolution up to 400dpi, it is
more important than ever that large pixel sizes work OK.
> In a few places I see 64-bit arithmetic utilized to control the
> overflow by means of FT_Int64. This integer type is not even
> documented.
They are local to the ftcalc.c module. And the stuff in fttrigon.c is
wrong, but gets never compiled due to an incorrect #ifdef. I'll fix
that.
> When is it ok to use this type?
Only in ftcalc.c, and you have to write two versions for use with and
without FT_LONG64.
> For example, when I calculate a dot product of 2 vectors, which is a
> very basic task. If dimensions are limited to 16-bits, the dot
> product would fit into 32 bits, so there is no need to worry about
> the overflow here.
Exactly. However, to multiply two 32bit entities, you need something
better, and 26.6 and 16.16 data types are frequently used.
If you *really* need some special computation with 64bit
intermediates, please add a function to ftcalc.c.
Werner
_______________________________________________
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel
