Re: [Devel] Integer issues with FreeType

[Antoine Leca]

David Turner wrote:
> 
> Antoine Leca a écrit :
> >
> > > 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.
> >
> What do you mean exactly ?

Signed integers have "bad" properties, such as being able to raise traps
in case of overflows, that unsigned don't have.
Also casts to signed while narrowing, a.k.a. demotion (exactly what you
said, as I understand) is undefined behaviour under ISO/ANSI C.

Now, the real problem is that I fail completely to understand the
point. If a compiler is verbose enough to be able to raise an
explicit warning in code like

  signed short x;  /* or FT_Int16 if you want */

  /* .. */
  x = x + 16;

I say this particular compiler is this mode is _not_ usable, so it is
probably not worth worrying about such a situation.

Now, it occurs to me I am probably missing the situation you have in mind.

> > 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.
> >
> There is an alternative way to "fix" this without affecting too much 
> performance.
> 
>   - first, define a given integer type (let's call it FT_Fast32 for now)
>     that is guaranteed to be at least 32-bit while still being fast to
>     use. This would be defined as
> 
>           #if FT_SIZEOF_INT == 2
>              typedef long           FT_Fast32;
>           #elif FT_SIZEOF_INT == 4
>              typedef int   FT_Fast32;
>           #else
>           #  error  Oh my, what's this weird platform of yours ??!
>           #endif
> 
>           typedef unsigned FT_Fast32    FT_UFast32;
> 
>     notice that this isn't the same thing than FT_Int32. I think we could
>     replace nearly all uses of FT_Long (except for storage issues) with
>     FT_Fast32 in the FreeType source code..

I had the same basic idea this week end, but a bit different. My idea is just
to use FT_Int throughout the code (where it matters of course), but to add
a precision that our FT_Int is *required* to be at least 32 bit wide.
In other words, FT_Int will be a synonym for int (so with _no_ performance hit),
except for the 16-bit boxes where long will be used instead. As a result, the
performance hit will be restricted to the (now disappearing) 16-bit boxes,
while still remaining compatible.

The only remaining point (as far as 16-bit portability is concerned) will be
when a 16-bit variable (that is, something that is *not* an internal variable
typed as FT_Int) is massaged by a computation that involves multiplication,
and then stored as FT_Int: on a 16-bit box, the intermediate computation
will be performed using 16-bit arithmetic, _then_ the result will be widened
to 32 bits when stored in the 32-bit FT_Int, resulting in wrong results.
The correction will the need to a early cast to FT_Int, which may apppear
completely useless to a programmer used to 32-bit boxes.
Since an example is much clearer than my explanations:

Let's have
  FT_Short16 ppem, pointSize;
  FT_Int     factor;

  /* ... */

  factor = ppem * pointSize / 72;

This is likely to raise overflow problems in 16-bit. The "correct" solution is
to write instead:

  factor = (FT_Int) ppem * pointSize / 72;

... which I expect most people to find completely useless!
Any advice?


Regarding your idea above, I do not agree with you we should *require* int
to be 32 bit wide (or even char to be 8 bit, but that's another story for
another day)... 64 bit ints should be perfectly OK, if we want to avoid hurting
the Alpha boys... ;-)


> FT_Int and FT_Long exist for convenience.

Thanks for the explanations. Can you cut-paste them in the "manual of style"?
(if such thing like doc/convntns.txt still exist)


Antoine