mIRC Home    About    Download    Register    News    Help

Print Thread
Joined: Jan 2004
Posts: 2,127
maroon Offline OP
Hoopy frood
OP Offline
Hoopy frood
Joined: Jan 2004
Posts: 2,127

If $crc64 needs to have the same syntax as $crc does, then it's fine to have it continue the behavior of requiring the 2nd parm instead of having it be optional like in the $sha* hashes. But if not, it would be great to be able to use $crc64(string) like we can with $sha1(string).

Also, it's fine to have $crc64 continue the compatibility with $crc where $crc64($null,0) is $null instead of all zeroes, and have $crc64(zero-byte-file,2) and $crc64(no-such-file,2) be the same as each other at zero.

However, $crc64 needs to always have its output be 16 hex digits. It's currently not left-zero-padding its output, which results in output occasionally being length 15 or shorter. If I tried enough random numbers I'd eventually get a shorter output that 10 digits:

//echo -a $crc64( test 981812576 ,0)

result: 86677859D7
should: 00000086677859D7

Also: //echo -a $crc64(no-such-file,2)

result: 0
should be: 0000000000000000

--

There are several different kinds of CRC64 floating around. There's the CRC64 defined in ISO 3309, and there's at least 2 different CRC64's both claiming to be ECMA 182.

The one being used by mIRC is probably the best choice of the 3. The ISO variant uses a polynomial containing very few bits, so a CRC64 of a very short string always has most of the hex digits being 0's. If the issue is detecting errors it transmitted data, it's not a problem. But if you're wanting the output to look like it's being spread pseudo-randomly across the 2^64 different outputs, it's not doing that.

The defunct crc64.online used the earlier variant of CRC64 claiming to be ECMA-182, and you can still test it in the wayback machine. That variant uses the same polynomial, but uses it mirrored left/right, and it doesn't do the logical-not of the CRC string before/after hashing the data, which results in the behavior where a differing quantity of leading 0x00 bytes in a binary string produces identical CRC64 outputs. Because mIRC didn't choose that variant, a CRC64 of 2 0x00 bytes will be different than the CRC64 of 1 0x00 byte.

Joined: Dec 2002
Posts: 5,411
Hoopy frood
Offline
Hoopy frood
Joined: Dec 2002
Posts: 5,411
Thanks for the feedback. The issue with the zero padding has been fixed for the next version.


Link Copied to Clipboard