[Devel] Integer issues with FreeType

[Tom Kacvinsky]

I plan on spending time this weekend going through the FT2 code base and
addressing the 64 bit long issue.  Before I do that, however, I want to get some
ideas from people about this.  Here is what I propose:

The FT_* and FT_U* integer types are defined in fttypes.h, but only after
ft2build.h is included.  This means we get (through a chain of includes) the
FT_IntN (and FT_UIntN) definitions from ftconfig.h.  Thus, we ought to be
defining FT_Long and FT_Int, etc... in terms of FT_Int32, FT_Int16, etc...
This is a first step torwards removing FT_Long, FT_Int, etc... all together
and using FT_IntN and FT_UIntN instead (which makes it very clear what size
the values are supposed to be).

But what the conundrum for me is that there is no documentation of what integer
size FT_Long, FT_Int, FT_Short, etc... are supposed to be.

So, what shall I do here?  Once I know what things are supposed to be, I can
work on adressing the issues at hand.  For instance, if FT_Int is supposed to be
16 bits wide, there are several things that I will need to check in the
Type1/CID/CFF drivers so that changing FT_Int to be 16 bits wide won't break
things.

I gather that the FT_* integer type definitions are based on the True Type
specification, so FT_Long is supposed to be 32 bits wide, and FT_Int is supposed
to be 16 bits wide (though I suppose that the TT spec uses short for this).
Etc, etc...

Then there is the ftcalc.c functions that need to be addressed.  Ugh.

Please do not not misunderstand me.  The code is working for me and many other
people, and I am not criticizing the code at all.  I just want to make the code
as portable as possible.  And this means I have to do things with macro
conditionals, because not all of the platforms FT runs on can use autoconf and
friends.

Anyway, the plan is for me to get another CVS scratch area set up on several
boxen that I have access to and test the changes locally.  I will then do a "cvs
diff -u -r" between two CVS trees and submit that to whomever wants to see it 
for
code review purposes.

Parting shot: all of this would be so much easier if every vendor out there had
C99 compliant C compilers.  Standards?  Hah!  We don't need no stinking
standards!

Regards,

Tom