[ft-devel] Re: Some public APIs using FT_Int/FT_UInt should be improved in future

[Werner LEMBERG]

>   typedef struct  FTC_BasicAttrRec_
>   {
>     FTC_ScalerRec  scaler;
>     FT_UInt        load_flags;
>
>   } FTC_BasicAttrRec, *FTC_BasicAttrs;
>
>   ...
>
>   FT_EXPORT_DEF( FT_Error )
>   FTC_SBitCache_LookupScaler( FTC_SBitCache  cache,
>                               FTC_Scaler     scaler,
>                               FT_ULong       load_flags,
>                               FT_UInt        gindex,
>                               FTC_SBit      *ansbit,
>                               FTC_Node      *anode )
>
> FTC_SBitCache_LookupScaler() takes FT_ULong load_flags
> from the 3rd argument, and write it to FT_UInt load_flags
> in the member of FTC_BasicAttrRec. It causes implicit cast
> in 16bit and LP64 platforms.

This is a bug, I think: FTC_BasicAttrRec should use FT_ULong for
`load_flags', as you suggest.

> In addition, FT_Get_SubGlyph_Info() may have similar problem.
> Current interface takes 2 pointers to FT_Int (p_arg1 & p_arg2).  In
> the case of TrueType font, the pointed values are used as the index
> of points in TrueType glyph shape description.  Yet I've not fully
> checked the TrueType instruction spec, I guess the number of points
> in TrueType would be 32bit, not 16bit.

I doubt that.  Reason: This part of the TrueType specification has
been there from the very beginning, and at that time (1991) almost
everything was 16bit.  We should be pragmatic, disallowing values
> 65535.


    Werner