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

[Antoine Leca]

On Wednesday, July 9th, 2008 , mpsuzuki wrote:
> On Tue, 8 Jul 2008 22:56:12 +0200
> Antoine Leca wrote:
>
> > On Wednesday, July 2nd, 2008, mpsuzuki noted:
> > > On many platforms, gcc does not set the value __STDC_VERSION__
> > > by default. Users have to set by -std=xxx option.
> >
> > On the other hand, it does not seem unreasonable to me to *require* 
> > bi-arch
> > compilers to operate in C99 mode, providing this is adequately documented:
> > as far as I understand, 32/64 bi-arch compilers are normally recent, so 
> > C99
> > ought to be available even if it is an option (as you pointed out for GCC
> > 3.x)
>
> Hmm, if C99-dependent bi-arch header file is installed as
> a part of FreeType2, I'm afraid that all softwares using
> FreeType2 should be compiled with C99-conforming C compiler.
> And, C99-unconforming C compiler should be refused (or warned
> at least) during the compilation including FreeType2 header.
> I think it's not welcomed except of the developers on the
> platforms whose compiler works in C99-mode by default.

Hmm, you are right, we were talking about the public headers and requiring 
C99 here, even for bi-arch toolchains, really hinders the portability of the 
library (think about the XYZ distro of Linux, whose maintainer uses a 
bi-arch compiler to simplify her job: this would restrict any FT-dependent 
package to be C99-conformant: clearly unreasonable).
So I have to retract my suggestion.


> Even if we restrict the scope to C99-conforming
> cpp, there is no portable cpp conditional to check the size
> of long.

This is a unimportant sidepoint, but you are slightly incorrect here: C99 
requires 64-bit support, so any C99-conforming cpp could correctly detect 
(using your first proposal, among other solutions) 64-bit int's or long's. 
You are correct it is impossible to detect larger than 64-bit architectures 
(for the same reason it is impossible to detect larger-than-32 with C90), 
but on the other hand neither do we care!


On a historical perspective, the real stuff was about detecting 32-bit 
int's, because several parts of the library could not be handled with 16-bit 
int, so we (well, David&Werner;-)) decided long ago to use (now named as) 
FT_Int32 everywhere, requesting it to be at least 32 bits.
Next phase, the problem was that the first choice for FT_Int32 was to use 
long: on 16-bit this is correct, and on classical 32-bit machines (read: 
"all computers are Vaxen/x86") where int and long are the same thing, this 
is harmless. However on newer (around 1997) computers things were different, 
long could be 64-bit with a performance penalty wrt 32-bit int; furthermore 
at the same time we had a necessity to handle some (few) operations using 
64-bit arithmetic. So we introduced the mechanism to select the "best" 
FT_Int32 and «FT_Long64» types, in the best (Standard-wise) way; the result 
is more or less what you are dealing with in ftconfig.h
Those notes are there to remember you that perhaps verifying the real use of 
this mechanism (and I guess there are differences between FT_Int32 and 
«FT_Long64» here), and perhaps revisit part of the whole thing. I know this 
is a hard job (that I do not have the free time to do right now), but if 
someone which understands about varying sizes of int and bi-arch etc. has 
some free time to invest, it should be rewarding.


Regards,
Antoine