Usability

[Daniel Marjamäki]

What can we do to improve the usability of Cppcheck?

Some ideas:
integrate addons better
integrate into builds better
review warnings and ensure they are intuitive
review the manual

[versat]

Add more library/configuration files, at least for widely used libraries, for example:
-Google Test
-Boost
-OpenMP
-OpenCV
-OpenGL
...

Enhance existing libraries.

Not sure if that really can be counted as a usability issue. But IMHO it would make using Cppcheck easier, more convenient and users may be more satisfied because of less FPs and errors and possibly more real bugs found during analysis.

[versat]

Personally i like the idea of a better addon integration. Especially via the commandline it is somewhat complex to call the addons. It would be nice if it is possible to just add a parameter to the Cppcheck command line like --addon=cert and it is automatically called (as long as python is found in the path). For addons with parameters maybe something like --addon="naming,var='[a-z].*'" works.

[Daniel Marjamäki]

But IMHO it would make using Cppcheck easier, more convenient and users may be more satisfied because of less FPs and errors and possibly more real bugs found during analysis.

Yes.

For addons with parameters maybe something like --addon="naming,var='[a-z].*'" works.

Yes I guess something like that would make addons more usable.

I would like for the misra.py that the misra rule texts parameter could be persistent somehow.

Personally i like the idea of a better addon integration.

just an idea. Imagine you put a file .cppcheck in a folder a/src

in that you can specify addons/suppressions/include paths/libraries/...

then whenever you check the files below a/src the settings in this file will be used.

you can then save cppcheck settings in a repo and whenever people check the repo those settings will be used.

[Alexander Mai]

Indeed having addons with very different requirements (python instead of native code, which maybe needs to be compiled from C++) is unfortunate. Running a single command line which produces a single result file is still the best...

[Richard Smith]

The largest complaint have from my team is the current ammount of false positives thrown by the MISRA addon. Until the per-file suppressions support was added our only option was to disable the rule globally which defeats the purpose of an automated checker.

We still have a farly large number of rules suppressed. I've been trying to check them with newer cppcheck versions and submit the ones that are still present back upstream for analysis but it takes time to construct the proper test cases to illustrate the failures. I still have several to re-check.

The 2nd largest complaint is the time it takes the checker (plus MISRA) to run. It's quite slow. Because of this we can't run it on every build target.

The manual says that using a cppcheck-build-dir will be helpful for speed increases but I've had complications making that work correctly with the MISRA addon in our CMake setup.

We use CMake for our build system with an out of tree build setup. So I would certainly vote for better integration of cppcheck proper and the addons.

The last item is that cppcheck with the --dump option liters our source tree with .dump files and again I wasn't able to figure out how to make cppcheck place those in our ./build/ directory.

[Paul Fultz]

For build integration at work we use a cmake module here:

https://github.com/RadeonOpenCompute/rocm-cmake/blob/master/share/rocm/cmake/ROCMCppCheck.cmake

This sets up an analyze target and a cppcheck target to run the analysis for the project. An example of that is here:

https://github.com/ROCmSoftwarePlatform/MIOpen/blob/master/CMakeLists.txt#L266

We could consider providing a cppcheck-config.cmake file so users can call find_package(cppcheck) and get special cmake functions to run cppcheck in their builds.

Also, it would be nice to integrate the addons by running --addon=addon.py. However, if we do such integration, it would be better for cppcheck to provide a direct API to python instead of going through an intermediate ast dump. This would allow addons to use cppcheck functions like isSameExpression, isOppositeCondition, etc directly from python.

Another thing would be to extend custom rules to check for valueflow values or check if two expression are the same or opposite. This could be done be selecting the token through the regex group. Although, we might need to find the parent in a regex group.

We could also improve the custom rules by auto escaping parenthesis, brackets, and other oprerators. This is because when you want to match an operator or bracket it is written as one word(ie x \[ \] or x \+ y) whereas when its used as a regex it is not a single word(ie [^{}] or \w+).

[versat]

Another idea that i had already some time ago is about improvements for easier usage of the library configuration files.
Projects (using Cppcheck) i have looked at (like Wireshark or digikam) seem to use only the standard library and POSIX or Windows (atomatically according to the platform).
Although they use for example Qt (heavily), they do not enable the qt.cfg. Maybe they do not even know that it exists.

IMHO it would be nice if Cppcheck could at least suggest using specific libraries if it finds some special keywords / symbols or whatever in the code.

I have also thought about automatically enabling library configurations if corresponding files (like *.qml) are found or keywords exist. This should be made optional, the question is if it is better to enable or disable it by default.

It would also make it easier to set up Cppcheck analysis for larger projects. BOINC is a relatively large project and uses WxWidgets and FreeBSD (depending on the configuration) for example. But to find this out one has to use --check-library, read / search through the source code, ...

[AnotherUser]

Random idea : Perhaps you could allow people to submit reports with statistics about the false-positive rate (in their view) for each test.

This could be done with custom suppression files - uploaded these files (false positive) in concert with statistics from an analysis run (reported positive), should allow the true-positive rate to be estimated.

Instructing users to upload these before modifying and re-analysing their source would help to improve the obtained stats. This data could be used to tag each check with an FPR/TPR value, which could be used by other users to filter reports (e.g. suppress all checks with TPR < 50%, and FPR > 50%).

Much more complex : allow for an auto-extract for the code that is responsible for triggering a reported bug. So if there is a bug on a given line, a .tar.gz file containing only the code that contributes to the warning could be extracted. This would simplify reporting FPs.

[Paul Fultz]

Much more complex : allow for an auto-extract for the code that is responsible for triggering a reported bug. So if there is a bug on a given line, a .tar.gz file containing only the code that contributes to the warning could be extracted. This would simplify reporting FPs.

In the tools there is a python script reduce.py that can reduce the case from a larger source which is helpful for reporting FPs. There is also creduce which can reduce cases much further. It is more agressive so its a good idea to run the case against the compiler to avoid getting a reduced test case that is invalid.

[michele]

I think a big improvement to speed up the cppcheck analisys would be, as compilers do, to check the files under analysis modification date and avoid to recheck files not modified: after a first run the execution time will be greately improved.

[AnotherUser]

PaulFultz: reduce.py is not mentioned in the manual, nor shipped with the debian package (I've not checked fedora). Looking at it, it doesn't seem to do very much - its quite empirical.

The code is around 200 lines long, and it seems to do things like remove comments and pre-processor lines (iteratively for some reason??) to reduce. This wont look at multiple source files, or actually extract the origin of some of these problems.

You would need to look at some merged source, like gcc -E, and relate it to cppcheck's parser to get the complete compiled source code. I've never seen creduce before, so perhaps this is helpful - will check. If it is actually helpful, having cppcheck integrate into this tool would be helpful.

[orbitcowboy]

We could improve usability for library usage:

• In case a user scans source code that contains includes like "boost" etc. and the corresponding library setting (--library=boost) is missing, then cppcheck could suggest it.
• In case cppcheck detects an unknown macro, it could internally lookup the available library files for this macro definition. Suppose it finds a corresponding definition, we could inform the user to include this library.
• We could introduce an option (e.g. --auto-detect-library) that automatically detects the required libraries.

[Daniel Marjamäki]

yes sounds reasonable.

[fuzzel]

I'm not sure if that is already possible but one thing that would help is if cppcheck could analyze one file out of a complete project. For example you have a cppcheck project file with all settings defined but you just want to analyze one file out of it instead of anaylzing the whole project:

"cppcheck foobar.c --project=myproject.cppcheck... "

At the moment you have to define all settings as command line parameters if you want to do a single file analysis.

[Daniel Marjamäki]

I'm not sure if that is already possible but one thing that would help is if cppcheck could analyze one file out of a complete project.

I think that sounds like a good feature to have. We should implement it. If you want... feel free to implement it and send a pull request. I guess you can tweak how ImportProject is used in cmdlineparser.cpp

For information... If you use a cppcheck build dir then Cppcheck will only analyze changed files. So if you only changed foobar.c then only that file should be analyzed.. However it does open and read all the files to see if they are changed. And you will get results for all files not just foobar.c.