Re: [ft-devel] C99, long long, and inline

[Werner LEMBERG]

>> Anyway, I am for the jump to C99 in 2.8.
> 
> I would argue against it.

Me too.

>> *long long*
>> Freetype emulates its own 64-bit arithmetic on LLP64 platforms
>> (like Windows) in order to stay ANSI.  This is crazy in this day
>> and age.  We should go C99 by default and and provide 64-bit
>> emulation only if a user begs for it in ftconfig.h.
> 
> The 'correct' thing to do (IMAO) is to use an int64_t (or ft_int64_t
> if you prefer) type.  On systems that provide int64_t, we have no
> problems.  On systems that don't provide it, then we can #define
> int64_t long long (or whatever is appropriate).  And finally, and as
> a last resort, we can drop back to an emulation if there is no
> native 64bit type available.

Yep.  This is the classic solution in autoconf style.  Alexei, do want
to give it a try.

>> *inline*
>> Freetype smooth rasterizer is very nested.  I seems to me that gcc
>> selects some inlining scheme.  Does anyone know how to check this?
>> I would like to have some control over inlining, which can be
>> useful for performance tuning.
> 
> Again, I'd argue for us just using 'inline' (or INLINE or FT_INLINE),
> and we can #define that as required.

Seconded.  Cf. the `AC_C_INLINE' autoconf macro.

>> *other C99 features*
>> Please voice your opinion.
> 
> Please, please, please can we avoid the practise of introducing
> variables other than at the start of a block?  When you suddenly
> have to get code that's been written in 'declare just in time' style
> working on compilers that don't support it, it's a massive pain in
> the behind.

Hehe.  I'm not aware of a C99 feature that we *urgently* need, and
that would considerably improve FreeType.


   Werner