[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[ft-devel] sign in conversion INT_MIN and FT_Render_Glyph (Re: Freetype-
From: |
Hin-Tak Leung |
Subject: |
[ft-devel] sign in conversion INT_MIN and FT_Render_Glyph (Re: Freetype-devel Digest, Vol 121, Issue 4) |
Date: |
Fri, 13 Feb 2015 18:45:43 +0000 |
I suggest putting
#define INT_MIN ((signed) 0x80000000)
and see if there is any warnings anywhere, for any compilers,
on a trial/testing basis.
This might catch some interesting and hidden bugs.
BTW, mingw header defines it in "include/limits.h" as:
#define INT_MIN (-2147483647 - 1)
There is probably no need to differ from them for windows?
--------------------------------------------
On Fri, 13/2/15, address@hidden <address@hidden> wrote:
Message: 2
Date: Fri, 13 Feb 2015 12:00:51 -0500
From: Alexei Podtelezhnikov <address@hidden>
To: Brian Sullender <address@hidden>
Cc: freetype-devel <address@hidden>
Subject: Re: [ft-devel] INT_MIN and FT_Render_Glyph
Message-ID:
<address@hidden>
Content-Type: text/plain; charset=UTF-8
Why is it supposed to work? I do not follow.
> #define INT_MIN 0x80000000
This might be an unsigned integer constant according to
standards.
When used, it may result in implicit type conversion to
unsigned for
the rest of calculations and comparisons: the hell breaks
loose. This
is a reason to
> #define INT_MIN (-2147483647 -
1)
- [ft-devel] sign in conversion INT_MIN and FT_Render_Glyph (Re: Freetype-devel Digest, Vol 121, Issue 4),
Hin-Tak Leung <=