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