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

[Robin Watts]

On 12/09/2016 14:35, Alexei Podtelezhnikov wrote:
> Anyway, I am for the jump to C99 in 2.8.

I would argue against it.

Freetype is used in many many more places that you can imagine; lots of 
them will have strange historical compilers. Straining them is a bad idea.

Personally I'd like to see freetype stay as C89, but to use some of the 
following features:

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

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

Relying on compilers to get optimisation right automagically is a mugs 
game. They can barely get compilation right...

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

Just my 2c.

Robin