Hello,
Nathan proposal to have a kconfig, with a default to the historical
algorithm, is a good solution.
I Maintain, DO NOT CHANGE THE DEFAULT CRC ROUTINE.
CRCs are relied upon for data structure integrity validation.
If you change the default, new code will consider valid data record as
invalid and STUFF IN PRODUCTION WILL BREAK
Compatibility with other platforms that do not define all the explicit
parameters of their CRC is a fallacy and is not a good enough reason to
break existing systems in a potentially dangerous way.
It's not worth the risk.
Sebastien
On 08/04/2025 06:43, Alin Jerpelea wrote:
+1 if there is backwards compatibility and proper documentation
On Tue, 8 Apr 2025, 04:00 chao an, <magicd...@gmail.com> wrote:
Hi, Gregļ¼
Glad to hear your voice.
In the current crc16 implementation, we have provided 3 variants. The
default crc16 semantics is CRC-16/XMODEM:
CRC-16/XMODEM:
crc16
crc16part
https://github.com/apache/nuttx/blob/master/libs/libc/misc/lib_crc16.c
CRC-16/CCITT-TRUE:
crc16ccitt
crc16ccittpart
https://github.com/apache/nuttx/blob/master/libs/libc/misc/lib_crc16ccitt.c
CRC-16/IBM:
crc16ibm
crc16ibmpart
https://github.com/apache/nuttx/blob/master/libs/libc/misc/lib_crc16ibm.c
In PR16147, I mapped the default crc16 implementation to CRC-16/IBM. NuttX
did not abandon other variants, but provided more specific interface
implementations:
https://github.com/apache/nuttx/pull/16147
CRC-16/XMODEM:
crc16xmodem
crc16xmodempart
CRC-16/CCITT-TRUE:
crc16ccitt
crc16ccittpart
CRC-16/IBM:
crc16ibm
crc16ibmpart
New crc16 implement, just mapping these APIs to CRC-16/IBM, developers are
free to choose which variant to use
This is not "JUST" mapping.
This JUST mapping will break production systems that use the old
implementation.
Dont do this.
I insist.
Sebastien
