为什么 Coverity 在 7.7 和 2020.12 版本中报告的错误对于相同的代码库是不同的?

问题描述

我正在迁移 Coverity 服务器,其中 Coverity 在旧服务器和新服务器上有 7.7 和 2020.12 版本。

我可以看到 Coverity 在这 2 个 Coverity 服务器上报告相同代码库的不同错误。大多数错误对于两台服务器都是常见的,但也有一些错误是最新版本的 Coverity (v 2020.12) 未报告但较早的 (Coverity 7.7 版) 报告,反之亦然。

如何判断新的 Coverity 服务器是否报告了合法的错误? 也想知道如果coverity版本不同,我们可以看到什么样的差异,这种差异的原因是什么?

解决方法

第一季度。我们如何确定新 Coverity 是否报告了合法错误?

您必须逐个检查差异,以查看每个差异是假阳性(不正确)还是真阳性(正确)。如果在合理的时间内有太多的人无法这样做,请随机抽样以获得统计估计。请注意,准确检查静态分析结果非常耗时;我通常为每个人预算 5-10 分钟。

第二季度。如果 Coverity 版本不同,我们可以看到什么样的差异?

实际上不可能对可能出现的定性差异作出任何限制。

从数量上讲,至少从历史上看,Coverity 开发人员试图确保不超过 5% 的“流失”,其中流失定义为:

  new false positives + lost true positives
  -----------------------------------------
           number of old findings

此 5% 规则适用于连续的主要版本。升级多个主要版本时的流失率可能更高。

对于新的真阳性或丢失的假阳性的数量没有限制。

第三季度。造成这种差异的原因是什么?

Coverity 工具正在不断开发中,其目的是(除其他目标外)发现更多真阳性和更少假阳性。就这一意图实现的程度而言,新结果应该比旧结果“更好”(总体上更准确)。

但是,与任何软件一样,在某些情况下可能会出现错误(或有意进行权衡),从而导致结果不太准确。

除了这些一般性声明之外,发行说明可能包含有关更改内容的其他详细信息。

相关问答

依赖报错 idea导入项目后依赖报错,解决方案:https://blog....
错误1:代码生成器依赖和mybatis依赖冲突 启动项目时报错如下...
错误1:gradle项目控制台输出为乱码 # 解决方案:https://bl...
错误还原:在查询的过程中,传入的workType为0时,该条件不起...
报错如下,gcc版本太低 ^ server.c:5346:31: 错误:‘struct...