Re: [boost] Re: Preview CRC version 8 (was: New file uploaded to boost)

From: Joel Young (jdy_at_[hidden])
Date: 2001-03-23 10:29:20

From: Daryle Walker <darylew_at_[hidden]>
Date: Fri, 23 Mar 2001 09:50:49 -0500

> Joel said:
>> I don't understand why (mycrc2.checksum() != 0) at the end of
>> the following code chunk.  Any suggestions?

> The comparison with zero cannot work if you use any reflections.  I say this
> for future reference, since you didn't use reflections in your example.

Of course not, but it is good to emphasize that.

> I assume that "header" is initialized somewhere, right?  And for the action
> you're trying to do, you have header->checkVal initialized to zeros, right?

Yes, header is initialized and is just a typecast on top of a buffer.
And yes, header->checkVal is initialized to zero.

> The second question is required for the trick I think you're using,
> but my classes cannot use this trick.  One philosophy of CRC assumes

But you show below how your classes (under restrictions) can use this
trick :-)

> the message is augmented with (number of bits in CRC) zero-filled bits
> before calculating.

Yes, this is what I am using.  I talked about the two philosophies in a
previous email to boost.  Oh and in regards to that email, Leon-Garcia,
Widjaja, "Communication Networks" is a book from McGraw Hill.

> The other philosophy doesn't require the extra zero bits.  I think
> you're trying the former, but I wrote the classes assuming the latter,
> and the two philosophies are incompatible.  (The first philosophy
> needs extra zero bits to shift out the CRC at the end of the
> polynomial division.  The second does the shift in the beginning, so
> the extra zero bits aren't needed, and would be interpreted as part of
> the real message instead!  The second philosophy works better with
> constant buffers, reflections, and interruptions.)

> For my classes, the first, and only the first, checksum computer must
> _exclude_ the ending bytes where the (zeroed) checksum would go.  In other
> words, try:

> mycrc.process_block( header, &(header->checkVal) );

Yes, thanks this worked wonderfully.  I don't quite know why I didn't
catch this before.

> You can leave the "mycrc2" lines as-is.  Then you should get zero from
> mycrc2's checksum.  As I warned, the zero-checksum trick only works if
> all reflections are off.  The only way to confirm checksums in general
> is to process only the bytes before the checksum, never include the
> checksum itself, and compare the checksums directly:

> mycrc2.process_block( header, &(header->checkVal) );
> assert( IPheader->checkVal == mycrc2.checksum() );

> padding.  This trick could break on CRC-ing a copy of a structure.

of course.

Thanks for this email.  I think that it could very easily become part of
the documentation for crc.  Especially the discussion of the two
philosophies.  Would it be reasonable to include an interface supporting
"philosophy 1" using the "philosophy 2" code with initial remainder=0, 
XOR val=0, and reflections set to false?

My problem came from trying to switch from a black-box crc computer,
where even the polynomial used is only implicitly documented by the
nest of loops, which implemented philosophy 1.

I am going to be OCONUS for a week so I'll check out the new(est)
version of CRC when I get back.

Thanks again,

Joel