What would a big-endian compatible version of this CRC32 method look like?

5
votes

I'm working on a project that requires a CRC32 check to be done on data that is being transmitted. I would like to make my code compatible for not only Intel architecture ("Little Endian"), but for Solaris architecture ("Big Endian") as well. I've found this "CCRC32" that works spiffy for two little endian machines, but utterly fails any cross platform tests:

Code:

CCRC32.h & CCRC32.cpp (taken off of wikipedia's "external links")

http://en.wikipedia.org/wiki/Cyclic_redundancy_check

Here is a method sample of the code:

void CCRC32::PartialCRC(unsigned long *ulCRC, const unsigned char *sData, unsigned long ulDataLength) {
while(ulDataLength--) {
    //If your compiler complains about the following line, try changing each
    //occurrence of *ulCRC with "((unsigned long)*ulCRC)" or "*(unsigned long *)ulCRC".

     *(unsigned long *)ulCRC =
        ((*(unsigned long *)ulCRC) >> 8)
             ^ this->ulTable[((*(unsigned long *)ulCRC) & 0xFF) ^ *sData++];
}




unsigned long CCRC32::FullCRC(const unsigned char *sData, unsigned long ulDataLength) {
    unsigned long ulCRC = 0xffffffff; //Initilaize the CRC.
    this->PartialCRC(&ulCRC, sData, ulDataLength);
    return(ulCRC ^ 0xffffffff); //Finalize the CRC and return.
}

So my question is this: Do you any of you big endian gurus know how to tweak the above methods to work with big endian machines, or does anyone know of an existing piece of source code that could accomplish my goal? I've been unsuccessful in my search thus far.

Thank you for your time,

James

1
c++endiannesscrccrc32
If you have problems with your crc implementation, it might be worthwhile to check out boost::crc: boost.org/doc/libs/1_46_1/libs/crc – stefaanv
I am having a very similar problem. If I feed byte order data into the ARM CRC hardware I get results (after complementing) that follow the CRC32 BZIP2 standard. If I then send data as 32 bit little endian words I get a different CRC result. When I deliberately re-order the bytes in the 32 bit word and then repeat the CRC I get back the result for BZIP2 CRC32. Although this makes sense; CRC being the remainder of a very long long-division; I am not sure if this weakens the CRC effectiveness. My guess is not BUT.... whats acceptable to a standards body for PROM checking... – user50619

1 Answers

3
votes

Not sure if it helps, but this piece of C code has big and small endian versions.