freetype-devel
[Top][All Lists]
Advanced

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

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


From: mpsuzuki
Subject: [ft-devel] Re: freetype-2.3.7 -- ftconfig.h for biarch systems
Date: Fri, 4 Jul 2008 13:05:15 +0900

Hi,

Sorry for the lated response.

FT_Int is required to store signed 32bit integer, but
the standard minimum of int type in C89 is signed 16bit.
Thus, if the int type is signed 16bit, we use
the long type that its standard minimum is signed 32bit.
Of course we have to check the long type can store signed
32bit (although there's no fallback). It is possible
that the type of FT_Int can be greater than signed 32bit
(e.g. think about ILP64 model).

In addition, we have similar task for 64bit integer.
If the long type can store signed 64bit integer,
we use simple 64bit calculation code in ftcalc.c.
If the long type cannot store, we use a pair of 32bit
integer and use an emulation of 64bit calculation.

In C99, int32_t (required) and int64_t (optional) are
defined, so they are what we wanted to find originally.
By using C99, FT_Int and FT_Int64 can be simplified?
Yes, if we ignore the binary compatibility with previous
releases.

In previous releases of FreeType2, configure checked
int and long only. Both are 32bit on most 32bit Unix.
In recent C99-conforming 32bit systems, often int64_t
(and long long) are introduced as 64bit integer (because
they are useful to seek large sized file, timers in
high resolution etc). So, how we can decide whether
FT_Int64 should be typed as int64_t or a pair of int32_t?

We can decide by checking INT64_MAX <= LONG_MAX
with C preprocessor? If true, previous configure ought to
define FT_Int64 by long and use simple 64bit calculation...
I wish so, but it's not reliable. Even if the code generator
(cc1) supports 64bit calculation, C preprocessor (cpp) is
not guaranteed to compare 64bit numerical constants correctly.
In fact, please try

#if ( INT64_MAX <= INT32_MAX )
# error cpp evaluates INT32_MAX >= INT64_MAX
#endif

on Tiny C compiler, instead of GNU C compiler. You will
receive an error. TCC insists the support of C99, but
its cpp can not handle the numerical constants unfitting
to signed 32bit (even if we add UL or ULL suffixes).
At present, I don't know standard preprocessor macros to
check the system is LP32/LP64/ILP64/LLP64. Even if we
restrict the scope to C99, C preprocessor cannot check
whether long type covers 64bit /or not. 

Thus, if we design configure-less and back-compatible
type definitions of FT_Int and FT_Int64, we must reject
the cpp without 64bit numerical constant support.

FreeType2 itself is built with cpp with 64bit numerical
constants, but other projects using prebuilt FreeType2
can be built with cpp without 64bit numerical constants.
For a fallback for such case, it is expected that running
AC_CHECK_SIZEOF([xxx]) and write the obtained values.

So my design is:

Check 1: if cpp has 64bit numerical constant support -
        define FT_SIZEOF_INT and FT_SIZEOF_LONG by
        the comparison of INT_MAX & LONG_MAX with
        0x7FFFFFFF and 0x7FFFFFFFFFFFFFFF.

Check 2: if cpp has no 64bit numerical constant support,
        consider the system specific macros that are
        useful to check LP32/LP64/ILP64/LLP64.

Check 3: if cpp has no 64bit numerical constant support
        and no reliable macros to guess the size of int
        & long, use the values obtained by running
        configure.

I want to hear the comments of the people who are interested
in supporting multiple architechtures by single ftconfig.h.

Regards,
mpsuzuki

BTW, it is possible for configure to decompose multiple
"-arch XXX" option and execute AC_CHECK_SIZEOF([xxx])
on each architecture.

On Wed, 2 Jul 2008 15:26:08 +0900
address@hidden wrote:

>As I've written, I will join the discussion tomorrow,
>but I have to note:
>
>On many platforms, gcc does not set the value __STDC_VERSION__
>by default. Users have to set by -std=xxx option.
>
>Regards,
>mpsuzuki
>
>On Wed, 02 Jul 2008 06:43:41 +0200 (CEST)
>Werner LEMBERG <address@hidden> wrote:
>
>>
>>> Yes.  __STDC_VERSION__ is defined as 199901L.  See for example:
>>> <http://lists.debian.org/debian-mentors/2002/10/msg00216.html>
>>
>>Thanks.  However, I think it would be better to test for `greater or
>>equal' than just for `equal'.
>>
>>
>>    Werner
>
>
>_______________________________________________
>Freetype-devel mailing list
>address@hidden
>http://lists.nongnu.org/mailman/listinfo/freetype-devel




reply via email to

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