Fix an overflow when casting from double to int

[Raziel-23]

An overflow may occur when casting double (8 bytes) to int (4 bytes), because double has a much wider range then int. It happens when I run dslstats program:

>>> gdb dslstats 
(gdb) r
Starting program: /home/raziel/dslstats64L-5.6/dslstats 
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/usr/lib/libthread_db.so.1".

Program received signal SIGFPE, Arithmetic exception.
FcRangeHash (r=<optimized out>) at fcrange.c:209
209         return b ^ (b << 1) ^ (e << 9);
(gdb) bt
#0  FcRangeHash (r=<optimized out>) at fcrange.c:209
#1  0x00007ffff420fce2 in FcValueHash (v=0xf58ca8) at fcpat.c:341
#2  FcValueListHash (l=0xf58ca0) at fcpat.c:371
#3  IA__FcPatternHash (p=0xf588e0) at fcpat.c:528
#4  0x00007ffff6548b81 in g_hash_table_lookup () from /usr/lib/libglib-2.0.so.0
#5  0x00007ffff443ee0d in ?? () from /usr/lib/libpangoft2-1.0.so.0
#6  0x00007ffff44445fd in ?? () from /usr/lib/libpangoft2-1.0.so.0
#7  0x00007ffff44404a9 in ?? () from /usr/lib/libpangoft2-1.0.so.0
#8  0x00007ffff5ee629f in ?? () from /usr/lib/libpango-1.0.so.0
#9  0x00007ffff5ee2790 in pango_layout_line_get_extents () from /usr/lib/libpango-1.0.so.0
#10 0x00007ffff5eeace6 in ?? () from /usr/lib/libpango-1.0.so.0
#11 0x00007ffff6ec3a5b in ?? () from /usr/lib/libgtk-x11-2.0.so.0
#12 0x00007ffff6858472 in g_cclosure_marshal_VOID__BOXEDv () from /usr/lib/libgobject-2.0.so.0
#13 0x00007ffff68607fc in g_signal_emit_valist () from /usr/lib/libgobject-2.0.so.0
#14 0x00007ffff6853c7a in g_signal_emit_by_name () from /usr/lib/libgobject-2.0.so.0
#15 0x00007ffff6ff7583 in gtk_widget_size_request () from /usr/lib/libgtk-x11-2.0.so.0
#16 0x00007ffff6ffeafc in ?? () from /usr/lib/libgtk-x11-2.0.so.0
#17 0x00007ffff6858472 in g_cclosure_marshal_VOID__BOXEDv () from /usr/lib/libgobject-2.0.so.0
#18 0x00007ffff6860f6a in g_signal_emit_valist () from /usr/lib/libgobject-2.0.so.0
#19 0x00007ffff6853c7a in g_signal_emit_by_name () from /usr/lib/libgobject-2.0.so.0
#20 0x00007ffff6ff4c77 in ?? () from /usr/lib/libgtk-x11-2.0.so.0
#21 0x00007ffff6fff6e7 in ?? () from /usr/lib/libgtk-x11-2.0.so.0
#22 0x00007ffff6860f6a in g_signal_emit_valist () from /usr/lib/libgobject-2.0.so.0
#23 0x00007ffff685377f in g_signal_emit () from /usr/lib/libgobject-2.0.so.0
#24 0x00007ffff6ffecf6 in gtk_widget_show () from /usr/lib/libgtk-x11-2.0.so.0
#25 0x00000000005d537f in ?? ()
#26 0x0000000000000000 in ?? ()
(gdb) info locals
c = {is_double = 1, is_inclusive = 0, u = {i = {begin = 0, end = 0}, d = {begin = 0, end = 1.7976931348623157e+308}}}
b = 0
e = 0
(gdb) 

As you can see just after running dslstats it receives SIGFPE signal which leads to its crash. The c.u.d.end value is 1.7976931348623157e+308 which is almost the maximum value of double type. This patch assure that when casting from double to int the result will be between valid range <INT_MAX, INT_MIN>. Even though this overflow is rare (for me it only occurs when I run dslstats), this patch may fix other similar crashes.

[bohoomil]

Thank you for the report and the patch. Has it been sent to the upstream yet?

[Raziel-23]

@bohoomil: To be honest I don't know where this patch can also be sent.

[Raziel-23]

@bohoomil I checked and this patch also fixes #81

[bohoomil]

Thank you very much for checking this out.

It seems like a good idea to submit the patch to the upstream at freedesktop.org and inform them that the patch solves these two issues. I believe this is a pretty crucial improvement that should be available in the stock fontconfig.

[Raziel-23]

@bohoomil I checked the release version (fontconfig 2.11.1), but there aren't such conversions. In the development version (git version) there are, but I installed the fontconfig git version and I'm unable to reproduce such crashes. I don't know well the source code of fontconfig, maybe they do something differently, but it appears that those crashes only shows up with the infinality version and are not related to the stock version. Nevertheless I'm glad that I helped and I want to thank you for the great job you are doing with this infinality version.