Re: [Devel] Integer issues with FreeType

[David Turner]

Hi Tom,

Tom Kacvinsky a écrit :
> 
> 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).
> 
Why would you want to remove these, they're perfectly legal..

> 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.
>
The sizes defined by the ANSI C specification, which is:

  FT_Short  == short  == 16-bits
  FT_Int    == int    == at least 16 bits, can be more (i.e. 24 bits, 32 bits, 
etc..)
  FT_Long   == long   == at least 32 bits, can be more (i.e. 36 bits, 64 bits, 
etc..)

You should use the FT_IntXX and FT_UIntXX types only when you
absolutely need an integer of an exact size. This is generally
used when you're dealing with the structure of integers in
memory, or when you need to perform exact wrapping, like in
"((FT_UInt16)(x + 16))"..

However, even if you read a 32-bit signed value from a file, there
is nothing wrong in storing it in a FT_Long (as long as you're not
going to perform arithmetic on it, like incrementing/decrementing
it).

Another source of problem is that the difference between pointers
can be larger than a FT_Long on some platforms (64-bit ones indeed),
which is why the FT_PtrDist type was introduced..
 
> 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.
> 
FT_Int isn't supposed to be a 16-bits int. You should not use it to
perform arithmetic on 1--bit values however, unless you take care of
casting everything appropriately..

> 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...
>
No, no, that's not correct, you're going to introduce lots of problem in the
source code if you do so, not mentioning adding about 100K compilation warnings 
:-)

> 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.
>
What do you mean exactly ?? I believe that the code in "ftcalc.c" is very
portable already (it may not be a best performer for many platforms however).
This code uses FT_Int32 and FT_UInt32 precisely because it's doing
arithmetic on 32-bit values..

We could improve the FreeType source code slightly to detect 64-bit integers
on a few compilers that support them like gcc, visual c++, etc.., without
using Autoconf if you like, but this doesn't need the deep inspection you're
mentioning..
 
> 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.
>
Tom, I think you're heading for trouble.. What really needs to be checked
are:

  - arithmetic computations with 16-bit and 32-bit quantities
  - use of pointer differences
  - casts (to see if they're applied appropriately)
 
> 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!
>
The old chicken and the egg problem. I'm really happy that we don't support
K&R C syntax though :-)

Cheers,

- David