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

2008-09-11 Thread mpsuzuki 
On Wed, 10 Sep 2008 21:34:21 +0200 (CEST)
Werner LEMBERG <[EMAIL PROTECTED]> wrote:
>> As I receive few comments on previous patch, I revised
>> my patch for more smooth migration.  [...]
>
>Looks good.  Thanks for your work!  Please apply.

Just I've committed.
I wish if I could fix the long open bi-arch issue.

Regards,
mpsuzuki


___
Freetype-devel mailing list
[email protected]
http://lists.nongnu.org/mailman/listinfo/freetype-devel

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

2008-09-10 Thread Werner LEMBERG 

> As I receive few comments on previous patch, I revised
> my patch for more smooth migration.  [...]

Looks good.  Thanks for your work!  Please apply.


Werner


___
Freetype-devel mailing list
[email protected]
http://lists.nongnu.org/mailman/listinfo/freetype-devel

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

2008-09-10 Thread mpsuzuki 
Hi all,

As I receive few comments on previous patch, I revised
my patch for more smooth migration.

1. The cpp computation of bit length of int & long
   was duplicated from original ftconfig.h designed
   for non-autoconf-systems:
   freetype-2.3.7/include/freetype/config/ftconfig.h.
   Its computation does not require C99 at all.

   I postpone the introduction of new header file to
   separate the cpp computation for easier maintenance.

2. Add a check to guarantee the cpp computation results
   is compatible with the results detected by autoconf.
   If there's any difference, the results detected by
   autoconf is prioritized by the definition of
   USE_AUTOCONF_SIZEOF_TYPES. However, we can set this
   macro manually by "--{enable|disable}-biarch-header",
   regardless with the result of the comparison.
   
   Because the check must parse unconfigured ftconfig.in,
   the sh script to compare them is ugly. When I can
   separate the cpp computation to individual file,
   the comparison would be more simple (maybe existing
   autoconf macro will help).

By the comparison by configure.raw, I think this patch
does not introduce any difference in single architecture
platforms.


Index: ChangeLog
===
RCS file: /sources/freetype/freetype2/ChangeLog,v
retrieving revision 1.1789
diff -u -r1.1789 ChangeLog
--- ChangeLog   5 Sep 2008 03:21:20 -   1.1789
+++ ChangeLog   10 Sep 2008 13:57:06 -
@@ -1,3 +1,15 @@
+2008-09-10  suzuki toshiya <[EMAIL PROTECTED]>
+
+   * builds/unix/ftconfig.in: Duplicate the cpp computation of
+   FT_SIZEOF_{INT|LONG} from include/freetype/config/ftconfig.h.
+   If USE_AUTOCONF_SIZEOF_TYPES is defined, the cpp computation
+   is ignored and the statically configured sizes are used.
+   * builds/unix/configure.raw: Add the checks to compare the
+   cpp computation result versus the sizes detected by configure.
+   If the results are different, USE_AUTOCONF_SIZEOF_TYPES is
+   defined. New option --{enable|disable}-biarch-header is added
+   to override USE_AUTOCONF_SIZEOF_TYPES manually.
+
 2008-09-05  suzuki toshiya <[EMAIL PROTECTED]>
 
* builds/unix/configure.raw: Clear FT2_EXTRA_LIBS when Carbon
Index: builds/unix/ftconfig.in
===
RCS file: /sources/freetype/freetype2/builds/unix/ftconfig.in,v
retrieving revision 1.23
diff -u -r1.23 ftconfig.in
--- builds/unix/ftconfig.in 2 Sep 2008 02:21:56 -   1.23
+++ builds/unix/ftconfig.in 10 Sep 2008 13:57:16 -
@@ -59,15 +59,54 @@
 
 #undef HAVE_UNISTD_H
 #undef HAVE_FCNTL_H
+#undef HAVE_STDINT_H
 
+
+  /* There are systems (like the Texas Instruments 'C54x) where a `char' */
+  /* has 16 bits.  ANSI C says that sizeof(char) is always 1.  Since an  */
+  /* `int' has 16 bits also for this system, sizeof(int) gives 1 which   */
+  /* is probably unexpected. */
+  /* */
+  /* `CHAR_BIT' (defined in limits.h) gives the number of bits in a  */
+  /* `char' type.*/
+
+#ifndef FT_CHAR_BIT
+#define FT_CHAR_BIT  CHAR_BIT
+#endif
+
+
+#undef USE_AUTOCONF_SIZEOF_TYPES
+#ifdef USE_AUTOCONF_SIZEOF_TYPES
 #undef SIZEOF_INT
 #undef SIZEOF_LONG
+#define FT_SIZEOF_INT  SIZEOF_INT
+#define FT_SIZEOF_LONG SIZEOF_LONG
+#else
 
+  /* The size of an `int' type.  */
+#if FT_UINT_MAX == 0xUL
+#define FT_SIZEOF_INT  (16 / FT_CHAR_BIT)
+#elif   FT_UINT_MAX == 0xUL
+#define FT_SIZEOF_INT  (32 / FT_CHAR_BIT)
+#elif FT_UINT_MAX > 0xUL && FT_UINT_MAX == 0xUL
+#define FT_SIZEOF_INT  (64 / FT_CHAR_BIT)
+#else
+#error "Unsupported size of `int' type!"
+#endif
 
-#define FT_SIZEOF_INT   SIZEOF_INT
-#define FT_SIZEOF_LONG  SIZEOF_LONG
+  /* The size of a `long' type.  A five-byte `long' (as used e.g. on the */
+  /* DM642) is recognized but avoided.   */
+#if  FT_ULONG_MAX == 0xUL
+#define FT_SIZEOF_LONG  (32 / FT_CHAR_BIT)
+#elif FT_ULONG_MAX > 0xUL && FT_ULONG_MAX == 0xFFUL
+#define FT_SIZEOF_LONG  (32 / FT_CHAR_BIT)
+#elif FT_ULONG_MAX > 0xUL && FT_ULONG_MAX == 0xUL
+#define FT_SIZEOF_LONG  (64 / FT_CHAR_BIT)
+#else
+#error "Unsupported size of `long' type!"
+#endif
 
-#define FT_CHAR_BIT  CHAR_BIT
+#endif /* ! USE_AUTOCONF_SIZEOF_TYPES */
 
   /* Preferred alignment of data */
 #define FT_ALIGNMENT  8
Index: builds/unix/configure.raw
===
RCS file: /sources/freetype/freetype2/builds/unix/configure.raw,v
retrieving revision 1.33
diff -u -r1.33 configure.raw
--- builds/unix/configure.raw   5 Sep 2008 03:21:21 -   1.33
+++ builds/uni

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

2008-08-18 Thread mpsuzuki 
Hi all,

Attached is a patch to support multiple architechtures that
use different sized integers (e.g. LP32 i386 and LP64 amd64).
At present, the patch is only for Unix-like platforms that
configure script proves the sizes for single architechture
and causes biarch problems (Savannah bug #21250, Mac OS X
issues). I have to note this patch is NOT the migration of
C99 that requires inttypes.h. I want to schedule the task
after the checking of 64bit support in FreeType2.

BTW, I want to ask a few questions to polish the patch...

Q1. the cpp computation of sizes of int and long should be
separated to another file (e.g. include/freetype/config/ftsiztyp.h)?

Apparently, the cpp computation of size of int and long is
very long. There is another static ftconfig.h (include/freetype/
config/ftconfig.h) and  non-Unix platforms can have their own
ftconfig.h (like builds/vms/ftconfig.h). Although it's little
needed to apply my patch to them, keeping their difference
small is important for the code maintenance. If moving the
part added by my patch to new file, it is easy for all ftconfig.h
to refer it (if needed). Also if it is separated, it is easy
for configure script to check cpp-computation results are
same with the results proven by configure script.

Q2. ftconfig.h should be bi-arch by default?

Today, most binaries of FreeType2 on Unix platformts are
configured for single architechture, by running configure
script, or by ftconfig.h written/modified manually. I don't
know their maintenance style in detail, but I don't want to
confuse them. The safest way would be the restriction of
the cpp computation of size of int and long for special
case (e.g. configure --enable-biarch-ftconfig).

Regards,
mpsuzuki
? root
Index: ChangeLog
===
RCS file: /sources/freetype/freetype2/ChangeLog,v
retrieving revision 1.1780
diff -u -r1.1780 ChangeLog
--- ChangeLog	18 Aug 2008 06:02:06 -	1.1780
+++ ChangeLog	18 Aug 2008 11:19:21 -
@@ -1,5 +1,12 @@
 2008-08-18  suzuki toshiya <[EMAIL PROTECTED]>
 
+	* builds/unix/ftconfig.in: Add a configure-less computation of
+	FT_SIZEOF_INT and FT_SIZEOF_LONG from limits.h. It can support
+	multiple and incompatible architechtures by single ftconfig.h.
+	This fixes Savannah bug #21250.
+
+2008-08-18  suzuki toshiya <[EMAIL PROTECTED]>
+
 	* src/base/ftmac.c: Add a fallback to suppose the availability
 	of ResourceIndex type. It is used when built without configure
 	(e.g. build by Jam).
Index: builds/unix/ftconfig.in
===
RCS file: /sources/freetype/freetype2/builds/unix/ftconfig.in,v
retrieving revision 1.22
diff -u -r1.22 ftconfig.in
--- builds/unix/ftconfig.in	28 Mar 2007 21:17:10 -	1.22
+++ builds/unix/ftconfig.in	18 Aug 2008 11:19:22 -
@@ -60,15 +60,135 @@
 #undef HAVE_UNISTD_H
 #undef HAVE_FCNTL_H
 
-#undef SIZEOF_INT
-#undef SIZEOF_LONG
-
-
-#define FT_SIZEOF_INT   SIZEOF_INT
-#define FT_SIZEOF_LONG  SIZEOF_LONG
-
 #define FT_CHAR_BIT  CHAR_BIT
 
+#define FT_IS_GE_NBYTE( x, n ) \
+  ( ( SCHAR_MAX ) <= ( ( x ) >> ( FT_CHAR_BIT * ( n ) ) ) )
+#define FT_IS_LT_NBYTE( x, n ) \
+  ( ( SCHAR_MAX ) >  ( ( x ) >> ( FT_CHAR_BIT * ( n ) ) ) )
+#define FT_IS_IN_NBYTE_RANGE( x, n ) \
+  ( FT_IS_GE_NBYTE( x, n - 1 ) && FT_IS_LT_NBYTE( x, n ) )
+
+
+/* check cpp can handle 64bit constant */
+#if ( 0x7FFFUL < 0x7FFFUL ) && !defined( USE_PROVEN_SIZES )
+
+# if ( INT_MAX < 0x7FFF )
+#  error Non-standard C whose int cannot cover signed 16bit 
+# elif FT_IS_IN_NBYTE_RANGE( INT_MAX, 1 )
+#  define FT_SIZEOF_INT 1
+# elif FT_IS_IN_NBYTE_RANGE( INT_MAX, 2 )
+#  define FT_SIZEOF_INT 2
+# elif FT_IS_IN_NBYTE_RANGE( INT_MAX, 3 )
+#  define FT_SIZEOF_INT 3
+# elif FT_IS_IN_NBYTE_RANGE( INT_MAX, 4 )
+#  define FT_SIZEOF_INT 4
+# elif FT_IS_IN_NBYTE_RANGE( INT_MAX, 5 )
+#  define FT_SIZEOF_INT 5
+# elif FT_IS_IN_NBYTE_RANGE( INT_MAX, 6 )
+#  define FT_SIZEOF_INT 6
+# elif FT_IS_IN_NBYTE_RANGE( INT_MAX, 7 )
+#  define FT_SIZEOF_INT 7
+# elif FT_IS_IN_NBYTE_RANGE( INT_MAX, 8 )
+#  define FT_SIZEOF_INT 8
+# else
+#  define USE_PROVEN_SIZES
+# endif
+
+# if ( LONG_MAX < 0x7FFF )
+#  error Non-standard C whose int cannot cover signed 16bit 
+# elif FT_IS_IN_NBYTE_RANGE( LONG_MAX, 1 )
+#  define FT_SIZEOF_LONG 1
+# elif FT_IS_IN_NBYTE_RANGE( LONG_MAX, 2 )
+#  define FT_SIZEOF_LONG 2
+# elif FT_IS_IN_NBYTE_RANGE( LONG_MAX, 3 )
+#  define FT_SIZEOF_LONG 3
+# elif FT_IS_IN_NBYTE_RANGE( LONG_MAX, 4 )
+#  define FT_SIZEOF_LONG 4
+# elif FT_IS_IN_NBYTE_RANGE( LONG_MAX, 5 )
+#  define FT_SIZEOF_LONG 5
+# elif FT_IS_IN_NBYTE_RANGE( LONG_MAX, 6 )
+#  define FT_SIZEOF_LONG 6
+# elif FT_IS_IN_NBYTE_RANGE( LONG_MAX, 7 )
+#  define FT_SIZEOF_LONG 7
+# elif FT_IS_IN_NBYTE_RANGE( LONG_MAX, 8 )
+#  define FT_SIZEOF_LONG 8
+# else
+#  define USE_PROVEN_SIZES
+# endif
+
+
+
+#else /* cpp cannot handle 64bit constant */
+
+  /*
+   * Here we list the environment that can execu

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

2008-07-16 Thread David Turner 
Hello,

2008/7/4 <[EMAIL PROTECTED]>:

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


this is not true, FT_Int corresponds to the standard C "int" type
that can be 32-bit or 16-bit. FT_Long is used when at least 32-bits
are needed

and of course FT_Int32 when exactly 32 bits are needed.

at least that was my intention when coding this. Please fix the
use cases / documentation where it doesn't match.



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

I encourage the switch to C99 integral types. It's 2008 now,
and any people who would want to use FreeType on an
old/embedded toolchain should need to port the sources itself
to support its environment.

this only really requires the following:

- all C99-specific configuration must happen in a few header files
  (e.g. ftconfig.h). the rest of the code uses things like FT_Int,
  FT_Long, FT_Int32, etc...

- we must be cautious about the possibility that 64-bit integral
  types are not available natively, so have a configuration option
  to use a pair of 32-bit integers instead, and still have the code
  working.

  however, the default would be to use a int64_t to define FT_Int64

I don't think it's unreasonable, and would allow us to get rid of some
fucking ugly stuff in ftconfig.h. And the less Autoconf we have, the
better...

Regards,

- David
___
Freetype-devel mailing list
[email protected]
http://lists.nongnu.org/mailman/listinfo/freetype-devel

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

2008-07-07 Thread Peter Breitenlohner 

On Sun, 6 Jul 2008, Werner LEMBERG wrote:


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).


Thanks a lot for your great analysis and code!  Please install
whatever you think is appropriate.


Yes, but unfortunately the situation is somewhat more complicated:

GNU/Linux has the commands:
setarch ARCH [CMD]
linux32 [CMD]
linux64 [CMD]
that execute CMD (or /bin/sh) under a slightly modified environment.
Depending on the hardware ARCH could be
i386/i486/i586/i686 vs. x86_64
ppc/ppc32 vs. ppc64
mips/mips32 vs. mips64
sparc/sparc32 vs. sparc64
etc., and linux32 or linux64 generically select the 32 or 64 bit variant.

E.g., for GNU/Linux on x86_64:
uname -m => x86_64
linux64 uname -m => x86_64
linux32 uname -m => i686
but
gcc
linux64 gcc
linux32 gcc
will all produce 64 bit binaries. Adding '-m64' yields the same 64 bit
binaries, but adding '-m32' will all produce 32 bit binaries.

Moreover, for gcc-3.3 and later on GNU/Linux i686 systems you can add 'gcc
-m32' without harm, whereas 'gcc -m64' will usually fail with an error
message.

However, with a little bit of trickery it is possible to build gcc with
'-m32' as default, such that gcc consists of 32 bit binaries, capable to run
and produce either 32 or 64 bit binaries on 32 or 64 bit systems.

=

Conclusion: I think for gcc on a potential biarch system you should try 'gcc
-m32' as well as 'gcc -m64' to detect its true nature. Independently of
that, ftconfig.h should use SIZEOR_LONG only as if no other possibility
exists. Such other possibilities could be
#include 
#ifdef __x86_64__
and analogous.

Regards
Peter Breitenlohner <[EMAIL PROTECTED]>


___
Freetype-devel mailing list
[email protected]
http://lists.nongnu.org/mailman/listinfo/freetype-devel

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

2008-07-07 Thread mpsuzuki 
On Mon, 7 Jul 2008 11:14:42 +0200 (CEST)
Peter Breitenlohner <[EMAIL PROTECTED]> wrote:
>>> * GNU/Linux (glibc-2.7) on amd64 & gcc-3.3 (default is LP64, -m32 makes 
>>> LP32).
>
>Yes, but unfortunately the situation is somewhat more complicated:
>
>GNU/Linux has the commands:
>   setarch ARCH [CMD]
>   linux32 [CMD]
>   linux64 [CMD]
>that execute CMD (or /bin/sh) under a slightly modified environment.
>Depending on the hardware ARCH could be
>   i386/i486/i586/i686 vs. x86_64
>   ppc/ppc32 vs. ppc64
>   mips/mips32 vs. mips64
>   sparc/sparc32 vs. sparc64
>etc., and linux32 or linux64 generically select the 32 or 64 bit variant.
>
>E.g., for GNU/Linux on x86_64:
>   uname -m => x86_64
>   linux64 uname -m => x86_64
>   linux32 uname -m => i686
>but
>   gcc
>   linux64 gcc
>   linux32 gcc
>will all produce 64 bit binaries. Adding '-m64' yields the same 64 bit
>binaries, but adding '-m32' will all produce 32 bit binaries.

Excuse me, I'm not sure what you want to say by linux64 and
linux32 command. My cpp code uses the symbols defined by cpp,
it does not use "uname -m" output at all. I tested on AMD64
and I think my sample works.

* If gcc on AMD64 is executed with -m64 or with nothing, its cpp
  defines __x86_64__, and __i386__ is undefined. It is same
  even if gcc is executed under linux32 or linux64. So my cpp
  code defines __LP64__.

* If gcc on AMD64 is executed with -m32, its cpp defines __i386__
  and __x86_64__ is undefined. It is same even if gcc is executed
  under linux32 or linux64. So my cpp code defines __LP32__.

What is wrong and should be corrected?

>Conclusion: I think for gcc on a potential biarch system you should try 'gcc
>-m32' as well as 'gcc -m64' to detect its true nature. Independently of
>that, ftconfig.h should use SIZEOR_LONG only as if no other possibility
>exists. Such other possibilities could be
>   #include 
>   #ifdef __x86_64__
>and analogous.

Sorry, I'm not sure what you want me to do by checking "-m32" and
"-m64", please let me know more detail. When the gcc is found as
biarch-ready (or not-ready), is there any difference that I should do?
In the first step of my cpp code, I defined FT_SIZEOF_INT and
FT_SIZEOF_LONG from C89 standard macros INT_MAX and LONG_MAX.
If cpp does not support the evaluation of 64bit numerics, other
non-standard macros specific to the systems, libraries and compilers
are considered.

Regards,
mpsuzuki


___
Freetype-devel mailing list
[email protected]
http://lists.nongnu.org/mailman/listinfo/freetype-devel

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

2008-07-06 Thread mpsuzuki 
On Sun, 06 Jul 2008 19:03:36 +0200 (CEST)
Werner LEMBERG <[EMAIL PROTECTED]> wrote:

>> 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).
>
>Thanks a lot for your great analysis and code!  Please install
>whatever you think is appropriate.

Thank you for positive comment. As a quick fix for this issue,
I will commit this, after small cleanup.
I guess the requirement of single config.h supporting multiple
arch/data-model/ABIs might be popular, so I posted to autoconf
list for further discussion toward to generic solution.

>> 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?
>
>Hmm.  What about running, say, the emx compiler in an MSDOS shell
>within a BOCHS (or DOSEMU) session?  A longer time ago I did this to
>check whether 16bit support still works.  It might be a good exercise
>to test this again.  Reason: 16bit compilers might detect problems not
>visible to 32bit compilers.

Also thank you for the information, I was not aware of emx compiler,
I will try. At present, the most easiest 16bit environment in
Debian GNU/Linux might be Bruce's C compiler and ELKS, but it's
oriented to GNU/Linux, I want to test on more older 16bit systems.

Regards,
mpsuzuki


___
Freetype-devel mailing list
[email protected]
http://lists.nongnu.org/mailman/listinfo/freetype-devel

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

2008-07-06 Thread Werner LEMBERG 
> 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).

Thanks a lot for your great analysis and code!  Please install
whatever you think is appropriate.

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

Hmm.  What about running, say, the emx compiler in an MSDOS shell
within a BOCHS (or DOSEMU) session?  A longer time ago I did this to
check whether 16bit support still works.  It might be a good exercise
to test this again.  Reason: 16bit compilers might detect problems not
visible to 32bit compilers.


Werner


___
Freetype-devel mailing list
[email protected]
http://lists.nongnu.org/mailman/listinfo/freetype-devel

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

2008-07-04 Thread mpsuzuki 
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 


#if ( 0x7FFFUL < 0x7FFFUL )

# 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 < 0x7FFFUL )
#  define FT_SIZEOF_INT 2
# elif ( 0x7FFF <= INT_MAX ) && ( INT_MAX < 0x7FFFUL )
#  define FT_SIZEOF_INT 4
# else
#  define FT_SIZEOF_INT 8
# endif

# if ( LONG_MAX < 0x7FFFL )
#  error Non-standard C whose long cannot cover signed 32bit 
# elif ( ( 0x7FFFL <= LONG_MAX ) && ( LONG_MAX < 0x7FFFUL ) )
#  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
[EMAIL PROTECTED] 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 resolutio

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

2008-07-03 Thread mpsuzuki 
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
0x7FFF and 0x7FFF.

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
[EMAIL PROTECTED] 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 <[EMAIL PROTECTED]> wrote:
>
>>
>>> Yes.  __STDC_VERSION__ is defined as 199901L.  See for example:
>>> 
>>
>>Thanks.  However, I think it would be better to test for `greater or
>>equal' than just for `equal'.
>>
>>
>>Werner
>
>
>___
>Freetype-devel mailing list
>[email protected]
>http://lists.nongnu.org/mailman/listinfo/freetype-devel


___
Freetype-devel mailing list
[email protected]
http://lists.nongnu.org/mailman/listinfo/freetype-devel