Re: [Devel] Integer issues with FreeType

[Antoine Leca]

David Turner wrote:
> 
[Tom]
> > 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..)

To be exact:
    FT_Short  == short  == at least 16 bits, can be more (i.e. 24 bits, 32 
bits, 64
bits, etc..)
    FT_Int    == int    == at least as wide as FT_Short, can be more
    FT_Long   == long   == at least as wide as FT_Int, AND at least 32 bits, 
can be
more

 
> 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))"..

I do believe this is true only for the unsigned ones,
i.e. I believe we should avoid using the signed versions.

But I am a purist on this theme (read on!)

 
> > 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 [16-bit] values however, unless you take care of
> casting everything appropriately..

Agreed.

In other words, if one use FT_Int (which I believe is the correct thing to
do for any "small" variable), the only point that should be checked vs. 16-bit
issues, is whether any computations, *including* internal sub-expressions,
cannot overflow a 15-bit value (of course, particular attention must
be exercised after *any* use of the multiplication operator, because
this is the principal culprit).
The "fix" for this is two-sided:
- one should use FT_Long for all internal variables that may exceed 15-bit;
- one should suffix with L any constant (such as 64 often used in the TrueType
  driver) that comes into action as operand of a * operator, when then
  other operand is, for any reason, typed as FT_Int (or FT_Short), and the
  (intermediate) result may overflow; equivalently, (FT_Long) casts may
  be used.
The result of this fix is a increased use of long all along the code,
which, particularly on a platform where (64-bit) long are wider than
(32-bit) int/short; and this leads to bigger size along with less
performances. The only gain is scalability back to 16-bit boxes.

Now, we had a test some weeks ago, and it showed that nobody really did use
Freetype 2 on a 16-bit box, ever (alternatively, one may believe that there
are not any 16-bit bug; I won't believe that).

So I am in favor to believe that, for Freetype 2, there is no urgent need
to walk along the whole source and fix, the way I described above, the code.


And the other hand, the way it was done (by Werner) in Freetype 1, when
compiling on a big platform with looong (i.e., wider than int) long's, one
can customize FT_Long to stay within the 32-bit range. Yes, this gains
performance and size. BUT this impeedes portability, and this is desastrous
for maintenance, since the obvious meaning is not the real one. I do not
believe there is any gain doing that.
As a result, I do not see any reason to keep FT_Int, FT_Long, etc., and
we may get back to the basic types, int, long, etc. Or do I miss something?
David?

 
> > 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!

You are believing that int64_t is C99 standard. Unfortunately, it is not
*mandatory* (only int_least64_t, and this does *not* solve your problem...)

And, if you wait for C99 compliant compiler*s*, do not hold your breath. I know
very well that they are not going to be popular these years, at least on all
the aspects (I grant you that the intXX_t types is one aspect that may come
very quickly, at least because this is part of XPG4 or 5).


Antoine