Dominique Pelle

CHR wrote: Why do you think that the missingIncludeSystem warnings are incorrect? You should be able to suppress them if you wish. cppcheck should be able to find all includes (system and application specific includes), since the compilation database should give all the include paths. As I wrote, I it reports this not only for system includes but also for includes from my application. The same compile_command.json works fine with plenty of other tools such as clang-format, clang-tidy, clangd, in...

Hi. I see a regression in cppcheck introduced between those 2 commits: 7fd4118d606b64dcb1c324d37248210a27094347 Mar 04 2023 -> FAIL <--- regression 50eb0641b9f1b0db4321a01713fbeed4a54ed304 Mar 04 2023 -> OK I analyze my project with cppecheck using using the compilation database (i.e. compile_commands.json file) in order to find compilation options (#defines, include path...) like this: $ cd cppcheck $ ./cppcheck --inconclusive --enable=all --project=...path_to_my_project.../compile_commands.json...

cppcheck does not detect this inefficient way of removing last character of a std::string: #include <string> std::string foo(std::string s) { // Inefficient way of removing the last character of the string // as it creates and moves a temporary string. s = s.substr(0, s.size() - 1); return s; } It could suggest this instead which does not create a temporary string: #include <string> std::string foo(std::string s) { s.pop_back(); return s; }

cppcheck does not detect this inefficient way of remove last character of a std::string: #include <string> std::string foo(std::string s) { // Inefficient way of removing the last character of the string // as it creates and moves a temporary string. s = s.substr(0, s.size() - 1); return s; } It could suggest this instead which does not create a temporary string: #include <string> std::string foo(std::string s) { // Inefficient way of removing the last character of the string // as it creates and...

Calling the std::equal_range() algorithm on a std::set or std::list container is silly. It's worse than O(n) complexity since std::equal_range() will internally call std::distance() and std::advance() which are both O(n) on a std::set or std::list, and they will be called O(log(n)) times, so the complexity ought to be n*log(n) which is worse than linear complexity. Yet it compiles fine and cppcheck does not detect any issue as in this silly example: $ cat $ cat foo.cpp #include <algorithm> #include...

fix: vim cscope test was failing on macOS Monterey (with M1 processor)

fix: vim cscope test was failing on macOS Monterey (with M1 processor)

docs: typo fixes in man page and in source code comments