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. 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? K.K. Excerpts from Alan Carvalho de Assis's message of July 15, 2022 5:45 pm: > This site is very good to compare and test CRCs: > > http://www.sunshine2k.de/coding/javascript/crc/crc_js.html > > The result is CRC32_JAMCRC as Karel pointed. > > So, just like CRC-16, there are many CRC-32 implementations. > > Since crc32() function is already used in many places on NuttX I don't > know the impact of including the bitwise "~" to return the most common > CRC32 value. > > BR, > > Alan > > On 7/15/22, Karel Kočí <cyn...@email.cz> wrote: >> >> Excerpts from Nathan Hartman's message of July 15, 2022 2:59 pm: >>> On Fri, Jul 15, 2022 at 8:10 AM Karel Kočí <cyn...@email.cz> wrote: >>>> >>>> Hi >>>> >>>> I hit an issue with crc32 implementation in NuttX's LibC and it took me >>>> some >>>> time to figure out that crc32 is implemented differently in NuttX than I >>>> was >>>> expecting. Let me explain... >>>> >>>> Common implementations are using same precomputed table as there is in >>>> the >>>> NuttX, but the initial value is all ones and not zero as in case of the >>>> NuttX >>>> (0xffffffff vs 0x0) and the result is negated while that is not true in >>>> the >>>> NuttX. >>>> In other words the call `crc32(msg, msgsiz)` gives "unexpected" result >>>> while >>>> `~crc32part(msg, msgsiz, 0xffffffff)` gives the "correct" one. >>>> >>>> I can see the idea behind not performing negation twice (`crc32part` >>>> would have >>>> to negate `crc32val` at the start and then return it negated again) but >>>> using >>>> the same precomputed table gives then different results. >>>> >>>> I am not sure if this weakens the crc32 in some way or just has no side >>>> effect >>>> except of not matching with common implementations. Either way this >>>> discrepancy >>>> should be at least documented with suggestion to use `~crc32part(msg, >>>> msgsiz, >>>> 0xffffffff)`. What do you think? >>>> >>>> With regards >>>> Karel Kočí >>> >>> >>> Hello, >>> >>> That is interesting. Which crc32 implementation are you comparing >>> against? (i.e., what do you mean by "common implementations"?) >> Well "common" I mean most of the implementations on the Internet (I know >> that >> there are load of variations) and used in our project (honestly just taken >> from the Internet). It also probably matches what for example others present >> on >> Wikipedia: >> https://en.wikipedia.org/wiki/Cyclic_redundancy_check#CRC-32_algorithm >> I do not think that the one implementation we are using is "the correct one" >> but >> it also seemed that NuttX implementation is not well defined either. >> >>> The CRC RevEng project at SourceForge [1] helps identify CRC >>> algorithms. Each algorithm is listed with the value it should output >>> when input the string "123456789" (as 8-bit characters). >> That is new for mew. I had no idea that there is such project. Looking into >> it >> more in depth I for example looked into which CRC32 variant implements zlib >> and >> that one uses CRC-32/ISO-HDLC. It is not hard to find it this way. Thanks >> for >> pointing this out. >> >>> But, when I run our algorithm as you suggest, with an initial value of >>> 0xffffffff, I get 0x340bc6d9 which is listed as the "check=" value of >>> "CRC-32/JAMCRC" [3]. >> You might have missed the binary negation. The difference between those is >> just >> a simple negation as it seems. The code `~crc32part("123456789", 9, >> 0xffffffff)` >> gives me 0xcbf43926 which matches the ISO-HDLC. Without the negation it >> gives me >> the answer you have. It makes sense as the difference is only in the final >> XOR >> and xor with zero does nothing while xor with ones simply does negation. >> >>> Based on a quick lookup there, it appears to me that the crc32() >>> implementation in NuttX should be what CRC RevEng calls >>> "CRC-32/CKSUM": width=32 poly=0x04c11db7 init=0x00000000 refin=false >>> refout=false xorout=0xffffffff check=0x765e7680 residue=0xc704dd7b >>> name="CRC-32/CKSUM" [2]. >>> >>> However, when I run our algorithm against the input string >>> "123456789", I don't get the value 0x765e7680 as listed above; I get >>> 0x2dfd2d88, which isn't listed as the "check=" value of any of the >>> algorithms. >> So at minimum this should be stated in the function documentation. >> >> I also tried to look into why it does not match that CKSUM algorithm but I >> pretty much failed. I am trying to tweak my own version that does not use >> table >> but still I get the invalid value (0xd202d277 which is negation of what you >> have >> and because that algorithm specifies xorout with ones that is probably >> little >> bit more correct). >> The only other difference between CKSUM and ISO-HDCL I can see there is in >> parameters refin and refout. From RevEng website it seems that it specifies >> >> endianess for input and output. The refin=false refout=false is stated as >> big-endian but I am not sure if I should perform calculation in big endian >> (which would make no difference if implemented correctly) or if only some >> part >> should be in that endianess. Just to be sure I also ran the code on Mips >> (MSB) >> but that gave me the same result (expected that). Thus I am not sure what >> those >> parameters mean in the end. >> >> K.K. >> >
pgpj8tJwPngF6.pgp
Description: PGP signature
