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

[Antoine Leca]

On Tuesday, July 1st, 2008, Sean McBride wrote:

> On 7/1/08 10:19 PM, Werner LEMBERG said:
>
> > > Can freetype use C99 features?
> > Not in general, but I don't object to put it into proper
> > #ifdef...#endif blocks -- AFAIK, C99 can be checked by a preprocessor
> > macro, right?
>
> Yes.  __STDC_VERSION__ is defined as 199901L.

Or would be a bigger value with the next versions of the standard.

> Currently freetype has things like:
>
> #if FT_SIZEOF_INT == (32 / FT_CHAR_BIT)
>   typedef signed int      FT_Int32;
>   typedef unsigned int    FT_UInt32;
<snip>
> In C99 this could simply be:
>   typedef int32_t     FT_Int32;
>   typedef uint32_t    FT_UInt32;
>
> No size testing required.  No problems with cross compilation nor
> universal binaries.

First, you should use int_least32_t etc. which are guaranteed to exist, 
while int32_t ain't so.
Next, as Werner says earlier, you whould really put this below a clause
   #if __STDC_VERSION__-0>=199901
   #include <stdint.h>
and then _keeps_ the existing text (with the first #if changed to #elif).


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.

Sure. This is because the STDC_VERSION mechanism is linked with the -std=c9x 
options: if you invoke the compiler with the -std=c99 option, you get the 
test macro as 199901L (and the above code could be brought in); however, if 
the compiler defaults to C90, you got no cookie (!) and are required to fall 
back at the present mechanism.

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)
I do not know what is the context with MacOS vs C99, but fortunately you 
should know more than necessary this about!

This puts 16/32 bi-arch compilers (like Digital Mars, or some targetting 
MC680x0) a bit out, but:
- this has been the situation for many years now, and to date it did not 
show as a top-ranking problem ;-)
- 16-bit Freetype is quite of exotic anyway (despite what I said earlier in 
this thread), so forcing 16/32 bi-arch compilers to operate in 32-bit mode 
does not seem a real stop.
Similar reasonment applies for multi-arch compilers (like those for 
microcontrollers).


Antoine