Re: [ft-devel] sign in conversion INT_MIN and FT_Render_Glyph (Re: Freetype-devel Digest, Vol 121, Issue 4)

[Hin-Tak Leung]

"possible" interesting and hidden bugs.

I assume somewhere a 0x8000000
is simply casted upwards, as in:

signed int64 something_else = INT_MAX;

and that's why it fails. Hmm, doing ((signed int) 0x80000000) doesn't really
result in new compiler warnings in this case, though it would actually
silently fix the problem.

Yes, since include/limits.ht in mingw defines it; I overlooked - Visual studio
does it too!

C:/Program Files/Microsoft Visual Studio 8/VC/include/limits.h:#define INT_MIN  
   (-2147483647 - 1) /* minimum (signed) int value */
C:/Program Files/Microsoft Visual Studio 9.0/VC/include/limits.h:#define 
INT_MIN     (-2147483647 - 1) /* minimum (signed) int value */

I don't have anything more recent. But yes, re-defining constants
in system headers is asking for trouble.

--------------------------------------------
On Fri, 13/2/15, Alexei Podtelezhnikov <address@hidden> wrote:

 On Fri, Feb 13, 2015 at
 1:45 PM, Hin-Tak Leung
 <address@hidden>
 wrote:
 
 > This might
 catch some interesting and hidden bugs.
 >
 > BTW, mingw header
 defines it in "include/limits.h" as:
 >
 > #define INT_MIN
 (-2147483647 - 1)
 
 Freetype does not redefine *standard* INT_MIN.
 If someone decided to
 break his system, it
 is their responsibility. What interesting
 Freetype bug you are talking about???