You can clone with
HTTPS or Subversion.
var hash = require("mhash").hash;
I believe the response should be AAC5A14F for crc32. I've tried this in ruby, php, and two online sources and they all agree. The expected decimal value would then be 2865078607 .
This package gets it right: https://npmjs.org/package/crc32
Let me know if I'm calling it wrong though or doing something else that's obvious. FYI, I'm on a 64-bit version of node.
Short story: this appears to be a problem with the mhash library itself.
Results from several libs and languages:
ruby : aac5a14f
python : 0xaac5a14fL
print hex(zlib.crc32("alejandro") & 0xffffffffL);
perl : aac5a14f
printf "%x\n", crc32("alejandro");
php : aac5a14f
java : aac5a14f
public class Test
public static void main(String args)
CRC32 hasher = new CRC32();
So all those seem to agree.
Note however the last PHP example was using hash("crc32b") to compute the correct hash.
If I use just regular hash("crc32") in PHP:
php : 1c7af1b5
Which is the same thing that the "mhash" lib creates:
var mhash = require("mhash");
Just to further verify that the node.js mhash binding code isn't faulty, I tried the Python mhash module:
python(mhash) : 1c7af1b5
hasher = mhash.MHASH(mhash.MHASH_CRC32);
The python bindings to mhash also produce the same result, so the node.js mhash binding code does not appear to be the problem.
It appears that the 'mhash' lib just uses some sort of different CRC32 algo than is standard in most languages.
In fact I've found other people having this same issue with CRC32 Checksums behaving incorrectly:
I haven't found any way to get the mhash() library to produce the same value that zlib and others do.
Ah okay... makes sense... as an mhash wrapper, this fix is understandably a bit out of scope for your lib. You'd only be introducing inconsistency with mhash.
I'll close. Thanks for the swift reply.