Re: [ft-devel] 16bit and LP64 model patch set (3)

[Werner LEMBERG]

> The easiest idea would be:
>
>       I1) replace internal cast to long in FT_NEXT_LONG() by
>       internal cast to FT_Int32.  It can reduce the shortening
>       implicit cast.
>
>       I2) as far as possible, replace FT_Long/FT_ULong by
>       FT_Int32/FT_UInt32.

What about

        I3) Use FT_Long, FT_Int, and friends for the API only (without
        changing the current semantics), and replace everything in the
        FreeType library with types which give the minimum bit width
        needed to hold the data.

I3 would be a long-term project since virtually everything is
affected.  Not a tough job, but rather tedious work.  At the time
FreeType has started, no-one has thought about those issues.

> To keep from forcing exact 32-bit types to non-essential parts, in
> this patch set, I used "FT_Fast" type which was introduced for the
> most appropriate type to hold at-least-32-bit value (which
> corresponds to C99 int_fast32_t).  Also I introduced the macros
> which cast the result to FT_Fast, FT_NEXT_FAST() etc.

This looks like a good start for I3.  I'm not really happy about the
word `fast' in the type name, but I probably have to get used to it
since C99 uses this term also.

> However, looking at the patched source, it is very very ugly.
> Mixing FT_Int, FT_Long, FT_Int32, FT_Fast is hell, all FT2
> developers won't to maintain such source.  I think the clarification
> of coding style regarding with 64-bit platform (which types should
> be used for each purpose) is required first, and rewriting the type
> definitions should be worked in next.

Yep.  To summarize, as far as I understand the issue:

  FT_Int: At least 16 bit.  For API only.
  FT_Long: At least 32 bit.  For API only.

  FT_Fast{16,32,64}: At least {16,32,64} bit internally.

Please correct me if I'm wrong.

I'm not sure whether we need FT_Int{16,32,64} which would hold values
with exact {16,32,64} bit.  We never rely on exact overflow semantics,
right?

I would also like to replace FT_Int32 with FT_Long within the API
(cf. FT_Load_Glyph), but I'm not sure whether this breaks binary
compatibility.


    Werner