恕敝人少见多怪
偶一直觉得这个CRC算法里面有一个重大的BUG,
就是对一个全0值的数据段进行CRC最后等到的结果居然是0
得到了一个全0的数据包，
而这个全0的数据包恰恰是在出现错误的时候最容易出现的，
然而校验结果居然正确。
假如说，在Flash芯片中存数据，528个字节中，512个存数据，剩16个存校验，
结果这528个字节同时被毁了，也就是说连CRC本身都毁了，都变成0了，
明明数据全都错了，而你处理程序却还傻傻的认为，CRC校验没有错误，数据还可以拿来用的。
又或者说，在数据传输过程中，产生了持续的干扰，使整个数据包的数据都变成全0，
当然，也许有人说了，哪有那么正好，是正好一个包那么多，
没错，但是也许是10.5个包，有1个包能检测出来，但是剩下的10个包都没有被法线错误。
偶不是说CRC算法的问题，而是说，这么一个弱智的BUG怎么会没有被发现呢，怎么还会使用了这么长时间呢。
偶窃以为，应该在生成CRC后，加上一个类似55AA的数据，
这样既不破坏CRC的强壮，也能防止全0包的出现。
再推导到其他校验算法
偶们常用的校验算法还有很多，
比如说常用的累加值校验算法，
这个算法也会产生同样的BUG,
有些是不能防全0数据，有些是不能防全1数据，
偶自己在做简单的累加和算法时，都会在累加数据上在加上一个固定值，
偶窃以为偶并没有改变算法本身的什么东东，只是改了一下表示方法，
不知道这种方法值不值得提倡。
这个问题偶想了好几年了，一直没好意思说出来。
今天斗胆发言，欢迎大家批评指正。
|
楼主
标题置顶
标题高亮
