freetype-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Antoine Leca
Subject: Re: [ft-devel] freetype-2.3.7 -- ftconfig.h for biarch systems
Date: Tue, 8 Jul 2008 22:39:58 +0200

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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]