Thanks for clearing that up, but I could use a little help altering the code. I've been looking through the online reference, and I'm failing to see where any of the methods I'm implementing allow you to change this...could somebody please point me in the right direction? Thanks.
----- Original Message ----- From: "Shawn Masters" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Friday, July 18, 2003 10:08 AM Subject: Re: Possible Bug in CRC32 This is a simple Endian problem. Just tell the HexEncoder which Endianness you want to encode as. It assumes Big Endian, and you will have to rework your code a little. 73, Shawn Matt "Cyber Dog" LaPlante wrote: > crc32 module of CryptoPP 5.1 on VisualStudio.net 2003: > > Using the following command line to calculate the CRC32: > const char* chars; > StringSource(chars, true, new HashFilter(crc32, new HexEncoder(new > StringSink(test)))); > ---or---- > FileSource(chars, true, new HashFilter(crc32, new HexEncoder(new > StringSink(test)))); > > ...where chars is either a text string, or a file path. > > The problem is the bytes come out in reversed order. For example, take the > string "hello": > actual crc32: 3610a686 > cryptopp crc32: 86a61036 > > As you can see, the bytes come out in reverse order. I've tested this > side-by-side with the Adler32 checksum, and Adler32 produces the correct > result using the exact same code, which leads me to believe the source of > the problem is in Crypto and not the code I'm using to access it. > >
