I found that cppcheck’s addon dump can produce MISRA diagnostics in a
non-source order.
In SymbolDatabase::printXml() (lib/symboldatabase.cpp), variables are
collected in std::set<const Variable*> before the <variables> XML section
is written. This orders records by object-pointer address instead of a stable
source key.
The MISRA addon reads that XML order into data.variables, and Rule 9.3 then
iterates data.variables directly. Therefore Rule 9.3 diagnostics can be
reported in a different order from the source order, making golden-output
tests flaky.
With the attached test.c, two separate executions using the same cppcheck
version and command produced the same three diagnostics in different orders.
Cppcheck version: 2.21.0
Platform: Windows
Expected diagnostic order:
line 24, line 25, line 27
I found that cppcheck’s addon dump can produce MISRA diagnostics in a
non-source order.
In
SymbolDatabase::printXml()(lib/symboldatabase.cpp), variables arecollected in
std::set<const Variable*>before the<variables>XML sectionis written. This orders records by object-pointer address instead of a stable
source key.
The MISRA addon reads that XML order into
data.variables, and Rule 9.3 theniterates
data.variablesdirectly. Therefore Rule 9.3 diagnostics can bereported in a different order from the source order, making golden-output
tests flaky.
With the attached
test.c, two separate executions using the same cppcheckversion and command produced the same three diagnostics in different orders.
Cppcheck version: 2.21.0
Platform: Windows
Expected diagnostic order:
line 24, line 25, line 27
Observed diagnostic order:
line 27, line 25, line 24 ("random" order)
Suggested fix: serialize addon variables using a stable key, for example
source file + line + column, or variable ID, rather than pointer order.