22

See the title. The returned value is 32 bits, right? Why not return an int?

Steveo
  • 2,238
  • 1
  • 21
  • 34

2 Answers2

22

Because if it returned an int, half of the CRC's would be negative. The expectation is that a 32-bit CRC is unsigned, i.e. 0..4294967295, which cannot be represented in an int.

Mark Adler
  • 101,978
  • 13
  • 118
  • 158
  • Mark, thanks for the answer. I have a follow-up: I am reading and writing files whose last bytes are a CRC of all the preceding bytes. The the CRC must fit in 4 bytes. So I cannot just ignore the upper 4 bytes of the long CRC, can I? I would need to convert the long to an "unsigned" represention first right? – Steveo Jun 13 '13 at 03:17
  • 1
    By definition, a 32-bit CRC fits in the low four bytes of the long. There is no unsigned 32-bit type in Java. – Mark Adler Jun 13 '13 at 05:17
  • 2
    The fact that the Java language does not support unsigned integer types is irrelevant here. Signed or unsigned any 32-bit value can be stored within a Java int, which is 32-bits in size. – bughouse26 May 01 '18 at 18:50
  • @bughouse26 Yet, that is why. – Mark Adler Apr 02 '19 at 19:07
10

java.util.zip.CRC32 implements the Checksum interface, which requires a long return type for getValue(), therefore requiring a long for a 32-bit checksum; the upper 32 bits of the output are almost definitely 0.

David Futcher
  • 320
  • 1
  • 7