I know the bit order must be most significant bit first, as it is doing division, in which is a math operation that requires the most significant digit to always be on the left.
However I'm not so sure about byte order. Since a stream of data to be checked is more than 1 byte long, it becomes a question of the correct byte order.
If you think of the string "ABCDEFG", the "A" is the first in the sequence of letters, but if treat the 7 character string as a 7 byte integer (where each letter is 1 byte), then the letter "A" is byte-0 only if you are talking about little-endian byte order. If you are using big-endian byte order then the byte-0 is actually corresponding to the letter "G".
So depending on your machine's endianness, the calculation for the CRC32 of this string could give TWO DIFFERENT OUTPUTS! This doesn't seem very reliable. How is this reconciled when calulating CRC32 (or any CRC for that matter)?
However I'm not so sure about byte order. Since a stream of data to be checked is more than 1 byte long, it becomes a question of the correct byte order.
If you think of the string "ABCDEFG", the "A" is the first in the sequence of letters, but if treat the 7 character string as a 7 byte integer (where each letter is 1 byte), then the letter "A" is byte-0 only if you are talking about little-endian byte order. If you are using big-endian byte order then the byte-0 is actually corresponding to the letter "G".
So depending on your machine's endianness, the calculation for the CRC32 of this string could give TWO DIFFERENT OUTPUTS! This doesn't seem very reliable. How is this reconciled when calulating CRC32 (or any CRC for that matter)?