[Kaffe] Help!, problems with ZipOutputStream.

Moses DeJong dejong at cs.umn.edu
Tue Feb 16 22:31:20 PST 1999

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

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

More information about the kaffe mailing list