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

[Antoine Leca]

Hi all,

Sorry for missing this thread, and sorry to respond in such an ugly way: I 
am
far away from my mail...


On Monday, June 30th, 2008, mpsuzuki wrote:

> Taking a glance on FreeType2 sources, it seems that the required
> information is "which type (or no type) is sufficient to store
> 32bit and 64bit numerical value", not the exact storage size in
> memory.

Very good point.
And it is a point that should be remembered; that is, if added code is 
written with the assumption that Int_32 is *exactly* 32 bits, it (IMHO) 
wrong.

This would drive out of the loop the proposal to use int32_t and their 
derivatives, whether they come from XPG's <inttypes.h> or the more recent 
C99's <stdint.h>. With C99 there exists an alternative named int_least32_t, 
but as Werner pointed out, C99 should *not* be required.


> So, I think, using traditional ANSI C header "limits.h"
> is more generic than using modern headers "bits/wordsize.h", like...
>
> #ifdef HAVE_LIMITS_H
>
> # if   ( UINT_MAX == 0xFFFFFFFFFFFFFFFF )
> #  define FT_SIZEOF_INT 8
> # elif ( UINT_MAX == 0xFFFFFFFFFFFF )
> #  define FT_SIZEOF_INT 6
> # elif ( UINT_MAX == 0xFFFFFFFF )
> #  define FT_SIZEOF_INT 4
> # else
> #  error XXX
> # endif

Of course it should be 8, 4 and 2, with the corresponding values (and while 
FT2 on 16 bits might appear foolish nowadays, I see no reason to remove this 
possibility; more exactly, if we required at-least-32-bit targets 
everywhere, most if not all of this discussion would become moot, we would 
use int everywhere unless 64 bits would be really required and the code 
would be easier to read... ;-) )

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; unsigned truncates, so 
0xFFFFFFFFFFFFFFFF would truncate to 0xFFFFFFFF, perhaps with a warning but 
this is not required; and the first test succeeds; of course, this is not 
what you want!


In general, with such snippets, you have to test your ideas with (of course) 
running versions of GCC and similar middle-of-the-road compilers, but you 
should also test it with something less mundane, more archaic.
For the people running x86 hardwares (Linux would require dosemu), the 
"historic" versions of Borland's Turbo C are compliant enough to the ANSI C 
standard to give a reliable estimation of the behaviour with 16-bit ints; 
and they are much easier to set up than the compilers targetting 
microcontrolers... I hope you get the idea for the other platforms.


Hope it helps,
Antoine