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 18:00:09 +0900

Here is a sample of cpp input which is based on
my previous post. I tested on:

* Mac OS X 10.4 on G3 PowerPC (default is LP32)
* HP-UX 11 on IA64 & HP C compiler (default is LP32. +DD64 makes LP64). 
* AIX 5.2 on ppc64 & Hitachi C compiler (default is LP32. -64 makes LP64).
* GNU/Linux (glibc-2.7) on amd64 & gcc-3.3 (default is LP64, -m32 makes LP32).
* GNU/Linux (glibc-2.7) on i386 & Tiny C compiler (default is LP32).
* FreeBSD 4.11 on i386 & gcc-2.95.4 (LP32 but inttypes.h has uint64_t).
* FreeBSD 6.2 on amd64 & gcc-3.4.6 (default is LP64, -m32 makes LP64).

Further discussion should be needed how precise
FT_SIZEOF_INT should be. Following sample just
checks from-16bit-to-31bit (recognized as 2),
from-32bit-to-63bit (recognized as 4),
64bit-or-more (recognized as 8). It's easy to add
more cases.

Also the requirement of support for 16bit-integer platform
should be discussed. Yet I don't have any good system to
run configure - anybody has access to legacy Minix for 8086?

Regards,
mpsuzuki

--------------------------------------------------------
#include <limits.h>


#if ( 0x7FFFFFFFUL < 0x7FFFFFFFFFFFFFFFUL )

# warning cpp can evaluate 64bit numerics

# 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

# if ( LONG_MAX < 0x7FFFFFFFL )
#  error Non-standard C whose long cannot cover signed 32bit 
# elif ( ( 0x7FFFFFFFL <= LONG_MAX ) && ( LONG_MAX < 0x7FFFFFFFFFFFUL ) )
#  define FT_SIZEOF_LONG 4
# else
#  define FT_SIZEOF_LONG 8
# endif

#else /* cpp cannot evaluate signed 64bit */

# warning cpp does not support 64bit numeric
  /*
   * Here we list the environment that can execute multiple ABIs
   * with different bitsize (e.g. IRIX on mips64, AIX on ppc64)
   * or build binary for multiple ABIs by single SDK (Mac OS X).
   * The environment that use single ABI or multiple ABIs but
   * same bit-length should be prepared by configure.
   */
# if defined( linux ) || defined( __FreeBSD__ ) || defined( __NetBSD__ ) || 
defined( __OpenBSD__ )
#  if   defined( __amd64 ) || defined( __ia64 ) || defined( __ppc64 ) || 
defined( __mips64 ) || defined( __sparc64 ) || defined( __sh64 )
#   define __LP64__ 1
#  elif defined( __i386 ) || defined( __ppc ) || defined( __mips ) || defined( 
__sparc ) || defined( __sh )
#   define __LP32__ 1
#  endif

  /* AIX */
# elif defined( _AIX ) /* See /usr/include/sys/limits.h */
#  if   defined( __64BIT__ )
#   define __LP64__ 1
#  else
#   define __LP32__ 1
#  endif

  /* HP-UX */
# elif defined( __hpux )
#  ifndef __LP64__
#   define __LP32__ 1
#  endif

  /* IRIX */
# elif defined( sgi )
#  if defined( _MIPS_SZLONG ) && ( _MIPS_SZLONG == 64 )
#   define __LP64__
#  else
#   define __LP32__
#  endif

  /* Mac OS X */
# elif defined( __APPLE__ ) && defined( __MACH__ )
#  ifndef __LP64__
#   define __LP32__
#  endif

  /* Solaris */
# elif defined( sun )
#  ifdef _LP64
#   define __LP64__
#  else
#   define __LP32__
#  endif

# endif

# if   defined( __LP32__ ) || defined( __LLP64__ )
#  define FT_SIZEOF_INT  4
#  define FT_SIZEOF_LONG 4
# elif defined( __LP64__ )
#  define FT_SIZEOF_INT  4
#  define FT_SIZEOF_LONG 8
# elif defined( __ILP64__ )
#  define FT_SIZEOF_INT  8
#  define FT_SIZEOF_LONG 8
# else

  /* 16bit platform support should be added here */

#  define FT_SIZEOF_INT  @SIZEOF_INT@
#  define FT_SIZEOF_LONG @SIZEOF_INT@

# endif

#endif

int main()
{
        int i = FT_SIZEOF_INT;
        int j = FT_SIZEOF_LONG;
        exit( 0 );
}


On Fri, 4 Jul 2008 13:05:15 +0900
address@hidden wrote:

>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]