Question

I found the code for adler32 here http://developer.classpath.org/doc/java/util/zip/Adler32-source.html

however my update code looks like following

private int a = 1, b = 0;

public void update(byte[] buf, int offset, int len)
{
    for (int i = offset; i < len; i++) {
        a = (a + buf[i]) % MOD_ADLER;
        b = (b + a) % MOD_ADLER;
    }
}

as oppose code on the link

public void update(byte[] buf, int offset, int len)
{
    for (int i = offset; i < len; i++) {
        a = (a + (buf[i] & 0xff)) % MOD_ADLER;  // <<=== Why & 0xff ?
        b = (b + a) % MOD_ADLER;
    }
}

I do not understand need to AND with 0xff as buf[i] is already 8 bytes, I understand it will be promoted to int as a is int, still the type promotion shouldn't change value in byte. May be I'm missing some more details as it doesnt work without & 0xff, I tested it with the values computed by java.util.zip.Adler32

Thanks for the answer, however it will only matter for values that result in negative numbers, for example in my test

    byte a = -4;
    int n1 = a & 0xff;
    int n2 = a;
    out.printf(" a %4d %s\n", a,Integer.toBinaryString(a));
    out.printf("n1 %4d %s\n",n1,Integer.toBinaryString(n1));
    out.printf("n2 %4d %s\n",n2,Integer.toBinaryString(n2));

prints

  a   -4 11111111111111111111111111111100
 n1  252 11111100
 n2   -4 11111111111111111111111111111100
Was it helpful?

Solution

The problem is that byte is signed in Java. Hence, the automatic type promotion byte -> int would always give a integer in the range (-128,127) instead of (0,255), as we want. The & 0xff operation fixes that.

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top