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"?) 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). 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. 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]. Anyway, please let us know which implementation(s) you're comparing against... References: [1] CRC RevEng project: https://reveng.sourceforge.io [2] Search for CRC-32/CKSUM on page: https://reveng.sourceforge.io/crc-catalogue/17plus.htm#crc.cat-bits.32 [3] Search for CRC-32/JAMCRC on page: https://reveng.sourceforge.io/crc-catalogue/17plus.htm#crc.cat-bits.32 Cheers, Nathan
