mz_crc32 fails on x86_64

[GoogleCodeExporter]

using a 32bit unsigned int instead of a 64bit unsigned long fixes the problem.

-mz_ulong mz_crc32(mz_ulong crc, const unsigned char *ptr, size_t buf_len);
+mz_uint32 mz_crc32(mz_uint32 crc, const unsigned char *ptr, size_t buf_len);

also the typedef for mz_uint32 must be moved to preceed this.

Original issue reported on code.google.com by ja...@cornsyrup.org on 24 Feb 2012 at 2:28

[GoogleCodeExporter]

This bug breaks some stuff on x86_64, such as extracting certain compressed 
files.

If you're having issues with x86_64, try these changes before giving up on this 
lib.

Original comment by kelw...@mtu.edu on 30 Mar 2012 at 6:50

[GoogleCodeExporter]

Confirmed.

Original comment by r...@eatenbyagrue.org on 22 Apr 2012 at 12:21

[GoogleCodeExporter]

same issue here but not with all files...and i noticed that under unix this 
happens more often. However the compressed files are not really damaged...only 
the crc32...to save the files already compressed force to ignore crc.
the patch suggested seems to fix. 

Original comment by aleba...@gmail.com on 24 Apr 2012 at 6:27

[GoogleCodeExporter]

Thanks for the reports - I'll try to repro this and figure out what's going on.

I would typically have used mz_uint32 here. I think I only used "mz_ulong" in 
this context to be more compatible with zlib types, which I think is somehow 
biting me here.

If mz_ulong is actually 64-bit I could see this function breaking. Let me see 
what I can find.

Original comment by richge...@gmail.com on 20 May 2012 at 12:12

• Changed state: Started

[GoogleCodeExporter]

Okay - it's definitely caused when mz_ulong is 64-bits. The CRC32 doesn't get 
computed properly because the high 32-bits have are set, and they get pulled 
into the CRC computation loop. I've checked all the other code that uses this 
type to ensure it doesn't have similar issues.

Here's one way to fix it. I'm going to release an update today that addresses 
this, as well as a few MinGW compilation warnings/issues.

// Karl Malbrain's compact CRC-32. See "A compact CCITT crc16 and crc32 C 
implementation that balances processor cache usage against speed": 
http://www.geocities.com/malbrain/
mz_ulong mz_crc32(mz_ulong crc, const mz_uint8 *ptr, size_t buf_len)
{
  static const mz_uint32 s_crc32[16] = { 0, 0x1db71064, 0x3b6e20c8, 0x26d930ac, 0x76dc4190, 0x6b6b51f4, 0x4db26158, 0x5005713c,
    0xedb88320, 0xf00f9344, 0xd6d6a3e8, 0xcb61b38c, 0x9b64c2b0, 0x86d3d2d4, 0xa00ae278, 0xbdbdf21c };
  mz_uint32 crcu32 = (mz_uint32)crc;
  if (!ptr) return MZ_CRC32_INIT;
  crcu32 = ~crcu32; while (buf_len--) { mz_uint8 b = *ptr++; crcu32 = (crcu32 >> 4) ^ s_crc32[(crcu32 & 0xF) ^ (b & 0xF)]; crcu32 = (crcu32 >> 4) ^ s_crc32[(crcu32 & 0xF) ^ (b >> 4)]; } 
  return ~crcu32;
}

Original comment by richge...@gmail.com on 20 May 2012 at 12:20

• Changed state: Verified

[GoogleCodeExporter]

This is fixed as of v1.13. I've credited you guys at the top of miniz.c. Thanks 
a lot for reporting this!

Original comment by richge...@gmail.com on 20 May 2012 at 4:41

• Changed state: Fixed