I've started to test cppcheck 2.7 and I've noticed in my tests runs that I have a large number of MISRA 2.4 and 2.5 messages. These are all false positive as they are used in our codebase. What seems to be happening is that my tests are via running things on a single test file. That file has includes for a bunch of other .c files that are not part of my check and get reported as unused.
In order to prevent these false positives it appears I have to check all of the files for the entire project. For us this takes a long time. (18.5 minutes) My teams workflow with cppcheck is for the developer to be able to run cppcheck on a single (or small number) of source items. Then the entire project is checked by a CI step or a test build.
How is cppcheck and MISRA 2.4/2.5 envisioned to be used in this sort of case? Am I going to to have some sort of conditional that knows when its only running on a subset of the project files an suppresses those messages?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
hmm.. good question. I fear that cppcheck will always run all the misra ctu analysis when it finish.
What seems to be happening is that my tests are via running things on a single test file.
I guess we could make an exception in the addon when only a single file has been analysed. Does this sound like a good solution or do you have better ideas?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I guess we could make an exception in the addon when only a single file has been analysed. Does this sound like a good solution or do you have better ideas?
Our spot check can check a variable number of files. I was only using one file in this case as a test. We typically use it to check all of the files that are changed as part of a changeset before it goes up in a PR and has the full CI run on it. Sometimes one file, sometimes several files, sometimes an entire directory of files. So using a single file as flag won't work.
My suggestion would be to provide a command line argument that enabled or disabled all of the rules that require analysis of the entire codebase. Something like --whole-project and --no-whole-project with the last option encountered being the one used. Then our spot check script would use --no-whole-project but if I wanted to use the same script to do project wide rule checking I would add --whole-project along with my list of files and it would override the previous --no-whole-project and enable the whole project rules.
For now it looks like I'll just have to suppress them.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
hmm.. I am very careful about adding extra options for cppcheck. I don't like tools that have 100's of options .. it's hard to find the options you want. in this case it's something that would be convenient but if I am not mistaken it's not really required to accomplish what you want.
I am not against adding another option to the misra addon. if you normally execute cppcheck with the option --addon then you can have separate json files for misra with whole program analysis and without whole program analysis.
Last edit: Daniel Marjamäki 2022-04-05
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Unfortunately, that would not work in my script without a lot of modification and having the script understand arguments. The script creates the misra.json file on the fly and then has the comment line passed in using ${@} Here's a snippit of the script that invokes cppcheck
Unfortunately, that would not work in my script without a lot of modification and having the script understand arguments. The script creates the misra.json file on the fly and then has the comment line passed in using ${@} Here's a snippit of the script that invokes cppcheck
I've started to test cppcheck 2.7 and I've noticed in my tests runs that I have a large number of MISRA 2.4 and 2.5 messages. These are all false positive as they are used in our codebase. What seems to be happening is that my tests are via running things on a single test file. That file has includes for a bunch of other .c files that are not part of my check and get reported as unused.
In order to prevent these false positives it appears I have to check all of the files for the entire project. For us this takes a long time. (18.5 minutes) My teams workflow with cppcheck is for the developer to be able to run cppcheck on a single (or small number) of source items. Then the entire project is checked by a CI step or a test build.
How is cppcheck and MISRA 2.4/2.5 envisioned to be used in this sort of case? Am I going to to have some sort of conditional that knows when its only running on a subset of the project files an suppresses those messages?
hmm.. good question. I fear that cppcheck will always run all the misra ctu analysis when it finish.
I guess we could make an exception in the addon when only a single file has been analysed. Does this sound like a good solution or do you have better ideas?
Our spot check can check a variable number of files. I was only using one file in this case as a test. We typically use it to check all of the files that are changed as part of a changeset before it goes up in a PR and has the full CI run on it. Sometimes one file, sometimes several files, sometimes an entire directory of files. So using a single file as flag won't work.
My suggestion would be to provide a command line argument that enabled or disabled all of the rules that require analysis of the entire codebase. Something like --whole-project and --no-whole-project with the last option encountered being the one used. Then our spot check script would use --no-whole-project but if I wanted to use the same script to do project wide rule checking I would add --whole-project along with my list of files and it would override the previous --no-whole-project and enable the whole project rules.
For now it looks like I'll just have to suppress them.
hmm.. I am very careful about adding extra options for cppcheck. I don't like tools that have 100's of options .. it's hard to find the options you want. in this case it's something that would be convenient but if I am not mistaken it's not really required to accomplish what you want.
I am not against adding another option to the misra addon. if you normally execute cppcheck with the option --addon then you can have separate json files for misra with whole program analysis and without whole program analysis.
Last edit: Daniel Marjamäki 2022-04-05
Unfortunately, that would not work in my script without a lot of modification and having the script understand arguments. The script creates the misra.json file on the fly and then has the comment line passed in using ${@} Here's a snippit of the script that invokes cppcheck
Unfortunately, that would not work in my script without a lot of modification and having the script understand arguments. The script creates the misra.json file on the fly and then has the comment line passed in using ${@} Here's a snippit of the script that invokes cppcheck
command line not comment line.