将 CRC 附加到末尾的缓冲区的 CRC 是否始终为 0？答案

【问题标题】：Is it always true that the CRC of a buffer that has the CRC appended to the end is always 0?将 CRC 附加到末尾的缓冲区的 CRC 是否始终为 0？
【发布时间】：2020-03-16 15:25:24
【问题描述】：

假设示例... 将CRC附加到末尾的缓冲区的CRC总是为0是否总是正确的？

extern uint16_t CRC16(uint_8* buffer, uint16_t size);  // From your favorite library

void main() {
   uint16_t crc; 
   uint8_t buffer[10] = {1,2,3,4,5,6,7,8};

   crc = CRC16(buffer,8);

   buffer[8]= crc>>8;      // This may be endian-dependent code
   buffer[9]= crc & 0xff;  // Ibid.

   if (CRC16(buffer,10) != 0) 
    printf("Should this ever happen???\n");
   else
    printf("It never happens!\n");

}

【问题讨论】：

标签： error-handling crc crc16 lfsr

【解决方案1】：

如果 CRC 在计算后被修改，例如某些 CRC 在生成后对 CRC 进行补码，则使用数据 + 附加 CRC 生成新的 CRC 将产生一个非零但恒定的值。如果 CRC 没有后置修改，则无论生成前 CRC 是否初始化为零或非零值，结果都将为零。

【讨论】：

【解决方案2】：

在末尾附加 CRC 的缓冲区的 CRC 总是为 0 是否总是正确的？

取决于 CRC，以及它是如何附加的。对于网络（以太网，V42..）中使用的 16 位和 32 位 CRC “CCITT”，no：最终的 CRC（按指定顺序附加）是 常量，但不为零：47 0F 用于 16 位 CRC，1C DF 44 21 用于 32 位 CRC。 16 位示例

-------- message --------            CRC-CCITT-16
01 02 03 04 05 06 07 08                 D4 6D
01 02 03 04 05 06 07 08  D4 6D          47 0F
DE AD BE EF                             CB E5
DE AD BE EF  CB E5                      47 0F

这在电信中很方便，处理接收的层通常知道帧只有在接收到 CRC 后才结束，该 CRC 已经输入到硬件中检查 CRC。

根本原因是8字节消息m0 m1 … m6 m7的16位CRC被生成多项式定义为/m0 /m1 m2 m3 … m6 m7 FF FF序列的余数。
当我们计算消息的 CRC 后跟原始 CRC r0 r1 时，新的 CRC 因此是生成多项式序列/m0 /m1 m2 m3 … m6 m7 r0 r1 FF FF 的余数，因此是生成多项式序列FF FF FF FF 的余数，因此是一个常数，但没有理由为零。

Try it online in Python!。包括 16 位和 32 位，“手动”并使用外部库，包括常数为零的库。

对于未附加正确位数或输出 CRC 错误字节序的 CRC（这些变体很多），结果取决于消息。这是一个确定的信号，表明有问题，相应地

接收方无法再将消息的 CRC 输入 CRC 检查器并将结果与常数进行比较以检查消息的完整性。
它丢失了 CRC 的理想属性，即任何集中在不超过 CRC 的位序列上的错误都会被捕获（如果我们没有直接得到 CRC，则错误会与消息的结尾和 CRC 重叠有时可能不会被发现）

【讨论】：