[Kaffe] Help!, problems with ZipOutputStream.

[Moses DeJong]

Hi all.

I have been looking at the src for the java.util.zip
classes and I am a little confused about this whole
signed vs unsigned thing. The code in ZipOutputStream
and ZipInputStream uses >> operations on long values
that have been cast to int values. First off, would
casting a long to an int keep the sign bit from the
long? If such a cast does keep the sign bit from the
long then it seems like casting a long to an int is not
the right way to get an unsigned 32 bit value out of
a long. In the class ZipInputStream, another method
where a long value is bitwise ANDed to 0xFF. It seems
like the code in ZipOutputStream should use this method
too. Here is an example of what I mean about the signed
shift issue. The example java code uses an unsigned shift
(>>>) and a signed shift (>>) and gets different results.
The C code does the same thing by using signed and unsigned
integers.


public class BitTest {
    public static void main(String[] argv) {
	int num = -8;
	
	System.out.println("num  is " + num);
	System.out.println("num1 is " + (num >>> 8));
	System.out.println("num2 is " + (num >> 8));
    }
} 

% java BitTest
num  is -8
num1 is 16777215
num2 is -1



int main(int argc, char ** argv) {
    unsigned int num1 = -8;
    int num2 = -8;

    printf("num is -8\n");
    printf("num1 is %d\n", (num1 >> 8));
    printf("num2 is %d\n", (num2 >> 8));
}


% gcc -o run bit.c
mo(/tmp/mo/tcljava/bugs)% ./run
num is -8
num1 is 16777215
num2 is -1


So I think a "fix" for the bit shifting and casting
problems is to use >>> and bitwise AND operators
to get the unsigned values out of the longs that
they are stored in. Does anyone agree or disagree?



Mo DeJong
dejong at cs.umn.edu