Jens Peter Secher wrote: > The Debian bug report is located at > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=348708 . > > As stated there, I do not think this is a bug. The crc.cpp file > explicitly changes the output depending on the endianess of the host > achitecture, so the result has to be interpreted as a word, not a > sequence of bytes.
Why is it working for MD5, then? Using the same code with an MD5 object returns the correct answer. Do I need an extra filter to make it endian independent and obtain the correct value for CRC32? One thing I agree with you: the code should produce the same hash independent of the machine endianness. I just don't understant why it is not so now. Anyway, all I want is a unified way to compute in small steps file hashes. By steps I mean using source.Pump(xxx) till there is no more input. I need this kind of behaviour because I want to add a UI interface. The interface needs to be responsive while computing the hash, even for big files. With filters, this is relatively easy to implement. Also, the only change needed to switch between MD5 and CRC32 is the transformation object (plus the need to output the correct CRC32). As I'm very new to libcrypto++, I fail to see how your code, using CalculateDigest, can be splitted in small parts. Cheers, -- Ionutz Borcoman http://borco.net/ http://developer.berlios.de/users/borco/
