Re: Use of FT_Long (= unsigned long) in psaux module

[Tom Kacvinsky]

Oops.  I meant signed long, not unsigned long.

> 
> Strange: I should have expected signed long; while unsigned long should
> be FT_ULong.
> But I did not actually look at the sources.
> 
> > in a few places where a 32 bit signed quantity is necessary. 
> 
> Sounds adequate to me.
> 

Yeah, there are enough bits there, but...

> > I write necessary because FT_Long is 64 bits long on a 64 bit box, and the
> > calculations that occur are done with 32 bit ints in mind.
> 
> What is the perceived problem? Are you saying that a 64 bit box does not
> adequately perform 32 bit calculations?

(FT_Long)(a << 24) | (FT_Long)(b << 16) | (FT_Long)(c << 8) | d

a, b, c, and d  are unsigned quantities.  Shifting an unsigned quantity
left 24 bits and then casting it to FT_Long does not set the sign bit
in the result, even if the sign bit is set (that is, 0x80 & quantity != 0)
in the quantity being shifted.

This has to to with Type 1 charstring numbers encoded as FF X X X X.

  
> There are cases it may occurs (when the specs are specifying the way overflow
> are to be handled), and in those cases, a masking operation of 0xFFFFFFFF on
> the result is required, but *first* this should not be allowed on _signed_
> operations, but rather an _unsigned_ one. However, I did not remember of this
> case about 32 bits quantities, but rather about 16 bits ones.
> 
> Can you be more precise with the problem you see?
> 

See above...

Tom