Sorry for the late response.. I was busy with life. Excerpts from Alan Carvalho de Assis's message of July 15, 2022 7:36 pm: > On 7/15/22, 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. >> >> I think that only documentation should be updated to prevent confusion as >> right >> now I would consider crc32 using the "non-starndard" (well it is not the ISO >> >> one) implementation. >> >> (I am now using here terms from that javascript page) >> >> Well.. it is not CRC32_JAMCRC. That is just CRC32 but without final "~". >> The closes to the current crc32 implementation in NuttX seems to be >> CRC32_POSIX, >> but with "Input reflected" and "Result reflected" set to true compared to >> the >> CRC32_POSIX. >> > > These are the results: > CRC32: 0xCBF43926 > CRC32_JAMCRC: 0x340BC6D9 > CRC_POSIX: 0x765E7680 > CRC_POSIX w/ Input and Output Reflected: 0xD202D277 > > So, according with your original comment, NuttX is returning > 0x340BC6D9, correct? No, NuttX's crc32 is returning 0x2DFD2D88! My modified code with missing negation returns that 0x340BC6D9 but that is now probably no longer relevant. We should now probably only consider what is the NuttX's crc32 implementation at the moment so its usage would be clear. I dragged there originally my requirement of the algorithm and in the end that got confusing.
The parameters that give me same test value from NuttX code as on crc_js.html: Input reflected: yes Result reflected: yes Polynomial: 0x4C11DB7 Initial Value: 0x0 Final Xor Value: 0x0 >> I think that just adding these parameters to the documentation of crc32 >> function >> should be enough.. possibly with warning that this implementation is unique >> to >> NuttX and probably should not be used for external communication. What do >> you >> think? >> > > I think we can rename the current crc32() to crc32_jamcrc(), or other > name we realize is correct to it, and use this name on FS code that > are using crc32() to avoid the issue. The NuttX's implementation should be probably something like `crc32_posixlike` as it is not even POSIX compliant implementation due to the input and output not being reflected and output not being negated. Thus possibly `crc32_nuttx`. With regards Karel Kočí
pgp37uwejHLxM.pgp
Description: PGP signature
