Re: Patches for t2gload (yet again)

[David Turner]

Hi Tom,

> 
> I found it.  The "offending" lines are the lines which make an integer
> out of a 1 or 2 byte encoded stream.  The following code:
> 
> #include <stdlib.h>
> 
> int main () {
> 
>   char k = 248;
>   long m;
> 
>   m = ( k - 247 ) * 256 + 32 + 108;
>   m <<= 16;
> 
>   printf ("%d %08X.\n", m >> 16, m >> 16);
> 
>   return (0) ;
> 
> }
> 
> Produced the output:
> 
> -65140 FFFF018C.
> 
> Which is *way* off of the expected value of 396.  By changing m to be
> an int instead of long, the problems went away. DEC's C compiler is
> treating signed chars as it should.  Thus, 248 as a signed char is -8,
> and from there, you can see where things go wrong.  But the resulting
> number is outside of the range of a signed int, so why shoving the
> result into a signed int "fixes" it, I don't know.
> 
> I suggest a cast as follows:
> 
> m = ((unsigned char)k - 247) * 256 + ....
> 
> which does work.  Another option (not likely, though), is to make all
> byte streams unsigned chars instead of signed chars...
> 

That's really strange, given that in t2gload.c, the "ip" pointer to tbe
byte stream is a FT_Byte* (i.e. pointer to unsigned char), and that the
variable "v", which replaces k in your example, is of type FT_Byte (i.e.
unsigned char) !!

Something must be really screwy there ???

- David

> Tom