
[Tim]
If WinZip unzips Jim's files without griping, the odds that he's got the wrong CRC are about 1 in 2**36 <wink>.
[JimA]
You mean 2**32, right?
Nope! For each of the 2**32 polynomials you may have pulled out of thin air, there are about a dozen common variations in the details of CRC algorithms. For example, a CRC used for hashing usually initializes "the register" to 0, but a CRC used to protect against transmission errors usually initializes to a block of 1 bits (since leading zeroes don't affect the result, and a common transmission error is dropping a prefix of the msg). Similarly, algorithms vary in the order they scan the data; in whether they use the raw data or its complement; and in whether they return the actual remainder, the complement of the remainder, or a checksum cleverly computed so that "the other end" always sees a fixed remainder other than 0 (or ~0).
Oh, sorry, you must be using a DEC-10 <wink again>.
I used a Univac 1108 in college, back when ASCII was in its infancy. They couldn't decide on the natural size for a character, so the 36-bit 1108 could be configured to treat each word as either 6 6-bit bytes or 4 9-bit ones. If they had been thinking ahead, they would have defined it as two Unicode characters plus a 4-bit tag field for the Python implementation to play with <wink>. now-they-make-their-living-suing-.gif-bandits-ly y'rs - tim