AVR C Runtime Library - Bugs: bug #45067, inconsistency & errors in...
You are not allowed to post comments on this tracker with your current authentication level.
bug #45067: inconsistency & errors in crc.h documentation
Submitter: | None | ||
Submitted: | Sun 10 May 2015 05:59:16 PM UTC | ||
Category: | Documentation | Severity: | 3 - Normal |
Priority: | 5 - Normal | Item Group: | Documentation |
Status: | None | Assigned to: | None |
Percent Complete: | 0% | Originator Email: | -email is unavailable- |
Open/Closed: | Open | Release: | 1.8.0 |
Fixed Release: | None |
Mon 25 May 2015 07:48:56 PM UTC, comment #2: |
Anonymous |
Sun 10 May 2015 06:22:54 PM UTC, comment #1: Unfortunately, the bit order of the CRC polynomial appears to
|
Joerg Wunsch <joerg_wunsch>![]() |
Sun 10 May 2015 05:59:16 PM UTC, original submission:
From http://www.nongnu.org/avr-libc/user-manual/group__util__crc.html:
|
Anonymous |
No files currently attached
Depends on the following items: None found
Items that depend on this one: None found
Powered by Savane 3.13-3230.
Corresponding source code
"Unfortunately, the bit order of the CRC polynomial appears to
be one of the things where there is never consensus about. :( "
I agree, so just pick one and be consistent about it. My point is that crc.h mixes both bit orders without even a comment explaining it.
And if you're going to pick one, I think the way pycrc does it is best because it is explicit as to when the polynomial division is bit-reversed. In cases where a CRC shows a polynomial in bit-reversed order, that's an implicit indication that it operates on the bits in reverse order (shift right instead of shift left).