Re: [ft-devel] freetype-2.3.7 -- ftconfig.h for biarch systems

[Antoine Leca]

Hi Suzuki-san,

> On Tue, 8 Jul 2008 22:39:58 +0200
> Antoine Leca wrote:
> > There is a real defect with the above approach: imagine a conforming C90
> > compiler with 32 bits being the widest type; on such a compiler, cpp would
> > evaluate the quantities using 32-bit arithmetic
<snip>

> So my revised proposal has the check of cpp feature:
>
> #if ( 0x7FFFFFFFUL < 0x7FFFFFFFFFFFFFFFUL )
> # warning cpp can evaluate 64bit numerics

Oh yes, this is really cute!

The only backpoint is that #warning is a GNU extension (which is likely to 
cause havoc on several other compilers).

On a technical sidepoint (read pedantic if you prefer), I know this is not 
100% conforming because cpp is not required to perform using the same 
arithmetic rule as the target, but this is a case for .001% of the cross 
compilers, so we can ignore it (add a comment if you want).
Formally you can drop the L suffix, it adds nothings (but does not break 
anything); of course you should keep the U suffix to avoid problem with 
signedness.


> # if ( INT_MAX < 0x7FFF )
> #  error Non-standard C whose int cannot cover signed 16bit
> # elif ( 0x7FFF <= INT_MAX ) && ( INT_MAX < 0x7FFFFFFFUL )
> #  define FT_SIZEOF_INT 2
> # elif ( 0x7FFFFFFF <= INT_MAX ) && ( INT_MAX < 0x7FFFFFFFFFFFUL )
> #  define FT_SIZEOF_INT 4
> # else
> #  define FT_SIZEOF_INT 8
> # endif
>
> (http://lists.gnu.org/archive/html/freetype-devel/2008-07/msg00010.html).

> The truncation (as a string process from the beginning)
> of too long numerical constant is de-jure behaviour in C90?

I think so, but the probability for occurences of bugs in this area is quite 
high, even for compilers seen as "ANSI conforming" by both its authors and 
its users, so you cannot really count on this. :-(


> I was misunderstanding that too long numerical constant
> causes some overflow in cpp. Considering the possibility
> of the string truncation from the end to fit 32bit integer,
> should I check another possibility like following?
>
> # if ( 0x7FFFFFFFUL < 0x000000017FFFFFFFUL )

I believe this is not necessary.
Okay, it's going to be a bit technical; you were warned.

Freetype effectively expects 8-bit char (I am not sure 9-bit chars or 16-bit 
chars could work or not, but I believe nobody checks it anyway). So we could 
restrict ourselves to the general cases, 16/32/64-bit etc.
Particularly if it is about detecting the size of int.

So either there is a limit with 32-bit so 0x7FFFFFFFul (case of most of C90 
compilers), or we step forward to include 64-bit support and 
0x7FFFFFFFFFFFFFFFul is the next frontier.

Furthermore, I remember David used in ftinter some properties of 32×32 
arithmetic (giving 64-bit results), and while my wild guess is that 33-bit 
or 34-bit should suffice according to the TT specs (David?), it is possible 
that our code really expects full 64-bit support.

Seeing a bit farther, many developpers will consider 64-bit support would be 
granted with types names like FT_Long64; and they may develop algorithms 
taking this as granted; and nobody will uncovers bugs there for those 
architectures where there is only 36-bit (like PDP-10) or 40-bit (like TMS 
microchips) targets...


Finally, I should say that the trick above is really a good one. Chapeau!


Regards,
Antoine