Version > 2.10 broken in our setup

[Richard Smith]

Hi,
I've reciently tried to update our cppcheck to something later than 2.10 to see if some of the false positives we see have been resolved but I'm unable to get anything > 2.10 to work. I have 3 different problems.

We drive cppcheck from conda setup via CMake setup and to run the misra add on we use a misra.json file like such:

"script": "misra.py",
"args": [   "--rule-texts=<file_path>/misra-rules.txt", 
            "-P <project_path>/src" 
        ]
}

Where the values in <> are paths that are generated by the CMake system. In 2.10 this works.

in 2.15 I get the following:
Did not find addon misra.py
but it only happens when running under conda. Running outside of conda that works.

I've been able to work around this issue by providing the full path to misra.py in the "script" statement.

But misra checking does not seem to be active. I have injected a MISRA 3.1 error into our code and it is not detected. Using the --checkers-report= option I've been able to acertain that the MISRA checker was not getting enabled.

Misra C
-------
Misra is not enabled

I've narrowed this down to the use of the --addon=misra.json If I use --addon=misra and run it outside of the conda environment then the checkers report indicates that misra is active and lists the misra rules. Using misra.json inside or outside of conda doesn't make a difference so this is different than the conda only issue for the script path.

Is using misra.json tested as part of the test suite?

But even after all that not using conda and --addon=misra I still don't get any misra 3.1 error indications. So even though it says they are active I don't think its really active.

As mentioned at the start version 2.10 works in our setup and finds my 3.1 error but it has false positives.

Any ideas on what to look at next?

[Daniel Marjamäki]

I can at least reproduce directly that the checkers report says that Misra C is not enabled. Even though I can see that misra.py is used.

$ ./cppcheck --addon=misra.json fp1.c --enable=all --checkers-report=r.txt
Checking fp1.c ...
fp1.c:2:7: style: misra violation 802 with no text in the supplied rule-texts-file [misra-c2012-8.2]
void f() {}
      ^
fp1.c:2:6: style: misra violation 804 with no text in the supplied rule-texts-file [misra-c2012-8.4]
void f() {}
     ^
fp1.c:9:26: style: misra violation 1004 with no text in the supplied rule-texts-file [misra-c2012-10.4]
           && (x[i] > x[i-1])) /* the culprit */
                         ^
.....

The misra.json I used:

$ cat misra.json 
{
    "script": "misra.py",
    "args": [   "--rule-texts=/home/daniel/usbstick/misra-rule-texts.txt",
            "-P /home/daniel/cppchecksolutions/cppcheck"
        ]
}

The file /home/daniel/usbstick/misra-rule-texts.txt contains the text for rule 8.4 so I don't feel cppcheck should say "misra violation 804 with no text in the supplied rule-texts-file".

And the checkers report output does say:

Misra C
-------
Misra is not enabled

Is using misra.json tested as part of the test suite?

It should but I can't point to the test off the top of my head.

I have created this ticket: https://trac.cppcheck.net/ticket/13144

[Richard Smith]

 --enable=all

I'm not using this option. Is it required for some reason?

[Richard Smith]

I see the issue now. Apparently there was a behavioral change. --enable=all makes the MISRA 3.1 deviation show up because it appears to now be classified as 'style' and in our project we are using --enable=warning,portability. style is not necessary for 2.10 to show these deviations.

Why are the misra rules behind any of these enables? If I run the MISRA addon I expect it to process all of the MISRA rules. (although I understand the newer threaded rules are preimum only) but even then if I enable MISRA then I expect to get all of MISRA. This is silently suppressing rules with no indication its happening.

Enabling style comes with a whole bunch of new messages. In our project any rule output from the static-check process is a CI failure. So style is going to make me add a whole bunch of new suppressions just to get back to matching the behavior of 2.10.

[Daniel Marjamäki]

Why are the misra rules behind any of these enables?

I have the feeling that there were people that complained that they would get style output even though they did not enable style explicitly.

But I agree also that it would make sense to write all the misra violations if --addon=misra is used.. that would be consistent with --premium=misra.. behavior.

[Richard Smith]

Are the tests included in a conda install? Where are you getting fp1.c from?

[Daniel Marjamäki]

fp1.c was some short random code I had that probably reproduced a false positive.

[Richard Smith]

What about the issue when running under conda? Were you able to duplicate that?

[Daniel Marjamäki]

I don't know anything about conda installs. I will ensure that 13144 is fixed soonish.

[Richard Smith]

Who makes the conda packages then?

[Richard Smith]

I'm not sure if this was the right place but I've filed:
https://github.com/conda-forge/cppcheck-feedstock/issues/94