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? > 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. BR, Alan
