>> 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 _______________________________________________ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
