skeeto
commented
2 years ago Update: Now that I've gotten a feel for its configuration, I'm leaning towards including Cppcheck in future releases. This has been the most useful "default" check configuration for me, and I'll probably capture it in a shell alias/function:
cppcheck --quiet -j$(nproc) --library=windows --enable=portability,performance --suppress=uninitvar .And this configuration is a good "strict" check — more thorough, but more false positives:
cppcheck --quiet -j$(nproc) --enable=portability,performance,style \
--suppress=uninitvar --suppress=unusedStructMember \
--suppress=constVariable --suppress=shadowVariable \
--suppress=variableScope --suppress=constParameter \
--suppress=shadowArgument --suppress=knownConditionTrueFalse .
Cppcheck is a static analysis tool that is easy to build and include in w64devkit (C++, no dependencies), and so I am currently evaluating its CLI program for inclusion in future releases. I'm using this pull request to solicit feedback from anyone following along who's interested in trying it out, particularly within w64devkit. Check out this branch, build the kit, and try out the new
cppcheckcommand. Is it useful in this context and worth including? Replies are also welcome in my public inbox.Cppcheck defaults to the appropriate platform (
--platform), so you don't need to set it. (I mention it since its documentation on this point is incorrect.) However, you may want to consider using--library=windowsto enable extra checks for programs using Win32 directly. I've decided to always use the--quietoption myself, and I'm surprised this behavior isn't the default.I've excluded all "addons" since they depend on Python, and I have no plans to ever include Python in w64devkit. I've also excluded the "platforms" since none of the non-built-in platforms are related to Windows. The goal is to include only the parts useful in a Windows development kit.
It even works in Windows XP, which is currently one of my requirements for included tools.
So far my reasons to not include it:
It adds about 2MB to the .zip release and 4MB to the install. That's not bad, but I strive to keep the kit as small as possible. This bulk comes from its ~100KLOC of template-heavy C++, which also takes several minutes to build.
Cppcheck doesn't publish a stable source release tarball. Instead it relies on GitHub's automatic tarball export, which changes without warning from time to time. It also requires Curl's
--remote-header-namefeature since GitHub's URL path doesn't end with a nice name. This all makes the w64devkit build more fragile. (Universal Ctags is in a similar situation, so I'm instead leaning on Debian to provide a stable source release. I can do the same here if I'm willing to give up some control and accept an older version.)So far in my tests a couple of Cppcheck's findings have been insightful, but that's out of maybe a hundred warnings. Every undefined variable warning, which is most of them, has been a false positive usually because it's confused about a loop. Generally I've found it's not so useful to run on my own code since I don't make the sorts of mistakes caught by Cppcheck, but it may still be useful when reviewing other's code.
It's slow, sometimes dreadfully so. In some cases it takes minutes with multiple threads and my fans running full blast to scan just a few thousand lines of code. I suspect there's a quadratic algorithm somewhere that gets caught on specific cases (example:
wordle.cin my scratch repository, ortokenize.cppin its own sources). It scans its own C++ sources at a dismal 34 lines per second (per thread) on my machine. The performance unpredictability would keep me from ever using it in an automated pipeline. This slowness is probably why--quietisn't the default: without progress updates, many users would suspect it's hung.Its slightly-non-standard option parser annoys me a little bit. :-) I keep wanting to write
-qj8instead of-q -j8, but it doesn't support option grouping. (Perhaps something to patch myself.)