[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: bugs in CRC32
From: |
Federico Montesino Pouzols |
Subject: |
Re: bugs in CRC32 |
Date: |
Thu, 9 Jan 2003 12:08:39 +0100 |
User-agent: |
Mutt/1.4i |
Hi,
On Mon, Jan 06, 2003 at 02:45:44PM -0800, Chad Yates wrote:
> I did a little research -- I'm not an expert on CRC algorithms, allthough I
> might be after all this ;)
>
> I did a myriad of searches on google to see if I could find out how many
> different versions of crc32 there are. I had hoped to find a definite
> answer, however, that doesn't seem to be the case. I found a document that
> discusses this problem
> (http://ce.sharif.edu/~cheraghchi/science/cs/crc_algorithm.htm if
> interestd).
>
I'll read it. In the meantime...
> it appears that the most common CRC32 version is the one for ethernet, and
> according to the above, is also "reportedly used in PKZip, AUTODIN II,
> Ethernet, and FDDI." I'm not familiar with ATM, so don't know if it uses a
> different version.
>
As far as I know, the ATM CRC32 is the same as the Ethernet one.
> anyway, according to the docs above this version has these distinguishing
> attributes. (The Check: value is the result of running it against
> '123456789').
>
> Name : "CRC-32"
> Width : 32
> Poly : 04C11DB7
> Init : FFFFFFFF
> RefIn : True
> RefOut : True
> XorOut : FFFFFFFF
> Check : CBF43926
>
We should include this specifications in the documentation to
avoid confusions.
> The fsum program I've been using to validate some of my tests also generates
> that number:
>
> ; SlavaSoft Optimizing Checksum Utility fsum 2.0 <www.slavasoft.com>
> ; Generated on 01/06/03 at 14:19:17
> cbf43926 ?CRC32*check.txt
>
> So, it should be pretty safe to assume that it is implementing the same
> version of the algorithm. the changes I made bring it into check with that
> version. It's really a shame that there is the possiblilyt of multiple
> versions masquerading as "CRC32" we may need to create 2 or more versions
> if we want to cover both the old and new versions. perhaps the code could
> be templatized (using template values) and be instantiated into digest.cpp
> for CRC, CRC16, CRC32_Ethernet, CRC32_ATM, etc... or , if those weren't
> enough they could just use the template directly like so:
>
> CRC<32, 0x04C11DB7, 0xFFFFFFFF, true, true, 0xFFFFFFFF>
>
> Its an idea anyway :) I might even be willing to pursue it if it sounds
> useful (for educational reasons)
>
I think it is a good idea.
> another idea may be to copy the code from the above doc (it says the code is
> public domain) and then have the commoncpp2 classes call it with the right
> parms. I don't know if it's fast or not. the current CRC32 creates tables
> everytime it's called, so I'd say it's not exactly efficient either (maybe
> the initialization should be moved to a class initializer?)
>
Yes, making the tables only once would be more efficient by
far. Does the code you mention produce the results expected by the
current crc32 demo for the ATM tests?
> thoughts?
>
> ,Chad
>