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)
Also: //echo -a $crc64(no-such-file,2)
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.