Hi,
Sorry to throw a rock in the pond but having a single function named
"crc32" is very wrong and is not sufficient.
As you have discussed the polynomial length is just not enough to
describe a crc, the initial value, bit orders of input and output, and
bit inversion on input and output are all used to derive actual crc
functions.
A proper API for an evolved project like nuttx should have a set of
functions like crc_init, crc_update and crc_final, all acting on a crc
context, just like sha and md5.
This would also allow specific implementations to use the hardware crc
resources provided by specific circuits.
This would allow each use of the crc routines to define and use its own
version of the crc, without interfering on other uses.
For example I agree it would be very unwise to change the CRC kind used
by file systems as it would break so many systems.
Sebastien
On 7/15/22 18:54, Karel Kočí wrote:
Excerpts from Nathan Hartman's message of July 15, 2022 6:47 pm:
On Fri, Jul 15, 2022 at 12:45 PM Karel Kočí <cyn...@email.cz> wrote:
The impact might be pretty significant from my search and that is also why I
rather discuss instead of suggesting changes.
The significant place where the current crc32 implementation is used is in
file systems (such as smartfs or nxffs). The change would break any existing
formating of those FSs. Thus I also do not think it should be done.
Are these file systems readable by other operating systems besides NuttX?
Those are NuttX only up to my knowledge. The change would break old formated
device on NuttX version update which sounds bad to me and "fix" (or rather let's
say change to some other crc32 algorithm) won't fix compatibility with some
other systems...
