CRC32 as .NET HashAlgorithm and endianness

Question

CRC32 is calculated as uint32, while HashAlgorithm in .NET by convention returns byte[]. I can, of course, easily convert it with bytes = BitConverter.GetBytes(hash) but this is affected by "endianness" of a system (almost no chance for big-endian, of course).

Anyway, I've been thinking is there any convention to follow? I have a feeling that it should be big-endian to make hash.ToString("X") and bytes.ToHex() (assuming .ToHex() exists) look the same.

I've checked https://github.com/vurdalakov/crc32/wiki/CRC32 and it does not do that. Any thoughts?

"Any thoughts?" is really too broad. Try to ask a specific question. Stackoverflow is not really geared toward ruminations. — President James K. Polk, Jan 27 '18 at 00:40

score 0 · Answer 1 · answered Jan 26 '18 at 00:16

0

I can only cite examples, where the zip and gzip file formats store the CRC in little-endian order. I'm sure someone can find examples where a 32-bit CRC is stored in big-endian order, sometimes called "network order" as big-endian is intended to be a convention for network communications.

If you are defining your own protocol, then you can pick whichever you like. For the code to be portable, you would need to use shift operators to pick apart the bytes so that the endianess of the machine does not affect the result.

answered Jan 26 '18 at 00:16

Mark Adler

101,978
13
118
158

Thanks. Still the question is, does it specifically do little-endian or it just stores native representation which happens to be little-endian? – Milosz Krajewski Jan 26 '18 at 12:55
What is "it" in "does it specifically" and "it just stores"? – Mark Adler Jan 26 '18 at 21:03

CRC32 as .NET HashAlgorithm and endianness

1 Answers1