Yes, I am able to open PR. https://github.com/danmar/cppcheck/pull/7856
Thanks for reporting, ticket is here: https://trac.cppcheck.net/ticket/14153
Cppcheck is more lenient than compilers so it is possible that invalid code can still be successfully analyzed. The same is actually true for clang-tidy which might also report findings even if you are getting compiler errors. If the code cannot be compiled to begin with I see no issue here.
Thanks for reporting. I filed https://trac.cppcheck.net/ticket/14151 about it.
Not a hijack. It's all related and has been around for quite a while and just got much worse. I need to report this upstream because I see nothing what we can do at our end. If possible, please use Clang as compiler for now since that does not seem to experience the issue.
To me it would be nice if the columns of the table were all parcelable out of the config files. If the formant had a name, short description, full description, and URL filed that might make maintaining the table easier. Also I wrote a short bash script below for getting the number of defines and functions of each config file. I think that information is useful so people can get some idea of how much is in the config files. cd ./cppcheck/cfg/ echo "| Name_of_cfg_file | Num_of_Defines | Num_of_Functions...
Hello, I just wanted to report a false positive syntaxError. My team uses brace init everywhere we can and we have some templates that make calls using explicit operator calls to get a value. Here is a simple example without a template. #include <iostream> #include <cstdint> struct callable { int operator()() { return 42; } }; int main() { callable c; std::int32_t const myint = c.operator()(); // <-- No syntaxError from cppcheck std::cout << myint << '\n'; std::int32_t const anotherint{ c.operator()()...
Hello, I just wanted to report a false positive syntaxError. My team uses brace init everywhere we can and we have some templates that make calls using explicit operator calls to get a value. Here is a simple example without a template. #include <iostream> #include <cstdint> struct callable { int operator()() { return 42; } }; int main() { callable c; std::int32_t const myint = c.operator()(); // <-- No syntaxError from cppcheck std::cout << myint << '\n'; std::int32_t const anotherint{ c.operator()()...
If you look at page 31 in the cppcheck manual https://cppcheck.sourceforge.io/manual.pdf There is a table in the library config section that looks like it didn't render as one would of expected.
Not to hijack this discussion, but the GUI crashes for me as soon as I open a project. I started a new one several times and the GUI is fine for editing. When I click analyze, it crashes. When I reopen it and attempt to reopen the project, it crashes. If I don't reopen the project and select edit instead, it opens the file for editing and I can make and save modifications. However, if I click open or analyze, it crashes every single time. Deleting everything and starting new does nothing. I have...
Are you able to open a PR at https://github.com/danmar/cppcheck/pulls?
Not to circumvent this discussion, but the GUI crashes for me as soon as I open a project. I started a new one several times and the GUI is fine for editing. When I click analyze, it crashes. When I reopen it and attempt to reopen the project, it crashes. If I don't reopen the project and select edit instead, it opens the file for editing and I can make and save modifications. However, if I click open or analyze, it crashes every single time. Deleting everything and starting new does nothing. I have...
Hi All, During the compilation of cppcheck in AIX using gcc compiler, I encountered the following errors: 1. /home/buildusr/reshma/cppcheck/cli/processexecutor.cpp: In member function 'bool ProcessExecutor::checkLoadAverage(size_t)': /home/buildusr/reshma/cppcheck/cli/processexecutor.cpp:288:9: error: 'getloadavg' was not declared in this scope 288 | if (getloadavg(&sample, 1) != 1) { | ^~~~~~~~~~ 2. /home/buildusr/reshma/cppcheck/test/signal/test-signalhandler.cpp:60:9: error: 'feenableexcept' was...
Hi All, I am building cppcheck in AIX using gcc compiler. The compilation fails with the following errors: multiple undeclared errors as shown below: /opt/freeware/lib/gcc/powerpc-ibm-aix7.1.0.0/10/include/c++/cstdint:47:11: error: 'int8_t' has not been declared in '::' 47 | using ::int8_t; | ^~~~~~ /opt/freeware/lib/gcc/powerpc-ibm-aix7.1.0.0/10/include/c++/cstdint:48:11: error: 'int16_t' has not been declared in '::' 48 | using ::int16_t; | ^~~~~~~ /opt/freeware/lib/gcc/powerpc-ibm-aix7.1.0.0/10/include/c++/cstdint:49:11:...
Hi All, I am building cppcheck in AIX using gcc compiler. The compilation fails with the following errors: multiple undeclared errors as shown below: /opt/freeware/lib/gcc/powerpc-ibm-aix7.1.0.0/10/include/c++/cstdint:47:11: error: 'int8_t' has not been declared in '::' 47 | using ::int8_t; | ^~~~~~ /opt/freeware/lib/gcc/powerpc-ibm-aix7.1.0.0/10/include/c++/cstdint:48:11: error: 'int16_t' has not been declared in '::' 48 | using ::int16_t; | ^~~~~~~ /opt/freeware/lib/gcc/powerpc-ibm-aix7.1.0.0/10/include/c++/cstdint:49:11:...
I'd recommend going through all the rules and their CWE mappings and moving any CWEs that are marked 'Discouraged' or 'Prohibited' (Don't know if there are any prohibited mappings), so the ones being used are not marked 'Discouraged' or 'Prohibited'. As examples, these rules use 'Discouraged' CWEs: arrayIndexOutofBounds is mapped to CWE 788 (CWE - CWE-788: Access of Memory Location After End of Buffer (4.18) https://cwe.mitre.org/data/definitions/788.html) - Maybe should be mapped to 125 or 787 if...
#define ASSERT(cond) { static const char condition_failed[(cond) ? 1 : -1] = {0}; (void)condition_failed[0]; } void func() { ASSERT(0); } This code does not compile: "error: size of array ‘condition_failed’ is negative" but cppcheck says: error: Array 'condition_failed[-1]' accessed at index 0, which is out of bounds. [arrayIndexOutOfBounds] I think there's something amiss in the analysis, no ?
When we run Cppcheck automatically, we run it in two phases: 1. with --check-config (disables normal code analysis) 2. code analysis per se The first time Cppcheck is run, phases 2 dominates: 1. ~ 1-2 minutes 2. ~ 13 minutes In subsequent runs, however, phase 2 is very fast, thanks to caching (--cppcheck-build-dir). If changes to the source code are small, phase 1 now dominates: 1. ~ 1-2 minutes 2. ~ 5-10 seconds Is there a way to cache the results of --check-config?
Thanks for also looking into it. I did the same and got it down even further (see also in https://github.com/danmar/cppcheck/pull/7798). void f() { auto* model = new QStandardItemModel; auto *item = new QCustomItem("0"); { QMap<QString, QVariant> itemdata; itemdata["file"] = "file1"; item->setData(itemdata); itemdata["file"] = "file2"; item->setData(itemdata); // crash } model/*->invisibleRootItem()*/->appendRow(item); model->clear(); delete model; } That produces thefollowing with GCC only ==26739==...
Hi Oliver Stöneberg, I made a test on my side. I just modified the gui/main.cpp to show a simple tree view. Below is the code change. diff --git a/gui/main.cpp b/gui/main.cpp index 22e1bc8cb..288dcdc3d 100644 --- a/gui/main.cpp +++ b/gui/main.cpp @@ -39,44 +39,43 @@ #include <QString> #include <QStringList> #include <QVariant> - +#include <QStandardItemModel> +#include <QTreeView> +#include <QScreen> static void ShowUsage(); static void ShowVersion(); static bool CheckArgs(const QStringList &args);...
As my testing, this is really strange. I also made a simple demo to try the TreeView outside the cppcheck project. There is no problem with the usage of QStandardItem::setData when not new the data. If we can find out what triggers the crash, maybe we can post a ticket to QT. I checked a sample under the QT SDK: /home/w01/Qt/Examples/Qt-6.9.1/widgets/itemviews/simpletreemodel In the demo, the model uses the smart pointer to hold the data. If we can't get the root cause of the crash, maybe that is...
As my testing, this is really strange. I also made a simple demo to try the TreeView outside the cppcheck project. There is no problem with the usage of QStandardItem::setData when not new the data. If we can find out what triggers the crash, maybe we can post a ticket to QT.
As my testing, this is really strange. I also made a simple demo to try the TreeView outside the cppcheck project. There is no problem with the usage of QStandardItem::setData when not new the data.
Hi Oliver Stöneberg, I made a test on my side. I just modified the gui/main.cpp to show a simple tree view. Below is the code change. diff --git a/gui/main.cpp b/gui/main.cpp index 22e1bc8cb..288dcdc3d 100644 --- a/gui/main.cpp +++ b/gui/main.cpp @@ -39,44 +39,43 @@ #include <QString> #include <QStringList> #include <QVariant> - +#include <QStandardItemModel> +#include <QTreeView> +#include <QScreen> static void ShowUsage(); static void ShowVersion(); static bool CheckArgs(const QStringList &args);...
Here's a guide on how to use a model: https://runebook.dev/en/articles/qt/qtreeview/setModel Unfortunately it does not set data on the items.
If I make itemdata (which is being passed to setData()) static it works. So it really appears to take a reference and that needs to be stored outside of the model. But changes to the object from the outside are not being propagated. It really looks to me like Qt is broken here.
If I make itemdata (which is being passed to setData()) static it works. So it really appears to take a reference and that needs to be stored outside of the model.
The view does not take ownership according to the documentation: https://doc.qt.io/qt-6/qabstractitemview.html#setModel
Unfortunately it is not fixing anything since now it leaks memory.
Unfortunately this only fixes the known failing test. The fix has been published as https://github.com/danmar/cppcheck/pull/7798.
I have a minimal reproducer and I think I found the issue. In ResultsTree we pass the address of QStandardItemModel to QTreeView. Based on other pattern in Qt I assume that the view will take ownership of the model and thus try to delete it. So that needs to be allocated instead. That at least fixes my reproducer.
While debugging something I suddenly experienced the issue again.
Yes. I experienced the issue myself multiple times and 100% reproducible but unfortunately I never got anything useful out of tools like ASAN or valgrind. And the stacktrace was detailed but I did not understand how it can be working fine on other platforms. And after updates to packages by the distro it usually went away for a while. Your observation appears to make sense but I checked the actual implementation of QStandardItem::setData() (see https://github.com/qt/qtbase/blob/d812e32bcba17f4be5a54c48651c3068487478f7/src/gui/itemmodels/qstandarditemmodel.cpp#L883)...
Hi Oliver Stöneberg, this is 100% reproduced on my side. Have you tested it with the Linux version? I think it is also possible to be related with the Qt version. I am using the 6.9. As my testing, this is involved by the commit 2e9b67c903322d2393f3d09435bedd186e178c32. (fixed #13133 - removed deprecated Qt5 support)
We have a known (but unreliable) crash in a test involving the results which I assume is the samer issue - see https://trac.cppcheck.net/ticket/13223. I have been trying to run the GUI tests with a sanitized build but that somehow fails to link. The work is included in https://github.com/danmar/cppcheck/pull/6820.
https://github.com/danmar/cppcheck/tags These usually do not result in an official Windows release being published but there is a public build artifact which contains them. They are also picked up by some of the third-party packagers. See https://github.com/danmar/cppcheck?tab=readme-ov-file#packages for more details.
I filed the follow tickets about this: https://trac.cppcheck.net/ticket/14108 https://trac.cppcheck.net/ticket/14109 https://trac.cppcheck.net/ticket/14110
Thanks! I can see that version 2.18.2 had been available for 2 days when I posted my message, but I had not found it. Is there a page which lists the versions X.Y.Z with Z != 0?
I may have made an assumtion because of this work on the sqrt function that the ranges were only used in bug hunting.
I have always found the cppcheck library config files to be a bit of a hidden gem. I have talked to developers who have been using cppcheck for years and they have no idea about it. So if you are reading this and you have no idea what a cppcheck library config file is you should read the manual and check out the list of libraries cppcheck has config files for https://github.com/danmar/cppcheck/tree/main/cfg My question is this is it only the value ranges in the library config files that are used...
As you said, 'Qt is weird with lifetimes and allocations', so this is depends on the Qt how to handle this. Actually, we don't know what Qt does. And there is a possibility Qt will implement the QStandardItem in a different way some say. If you can't reproduce this, I think it is a little difficult for us to track this issue. I am using the ubuntu and QT 6.9. And the test file for cppcheck: #include <stdio.h> int func(int a, int b = 100) { return a+b; } int call(int var) { return 100; }
As you said, 'Qt is weird with lifetimes and allocations', so this is depends on the Qt how to handle this. Actually, we don't know what Qt does. And there is a possibility Qt will not support that some day. If you can't reproduce this, I think it is a little difficult for us to track this issue. I am using the ubuntu and QT 6.9. And the test file for cppcheck: #include <stdio.h> int func(int a, int b = 100) { return a+b; } int call(int var) { return 100; }
As you said, 'Qt is weird with lifetimes and allocations', so this is depends on the Qt how to handle this. But in normal, this will cause problems for sure. Actually, we don't know what Qt does. And there is a possibility Qt will not support that some day. If you can't reproduce this, I think it is a little difficult for us to track this issue. I am using the ubuntu and QT 6.9. And the test file for cppcheck: #include <stdio.h> int func(int a, int b = 100) { return a+b; } int call(int var) { return...
I posted the bt trace in the previous post, don't why that can't be shown. I copied it again: #0 0x00007a245d5c1e5e in QtPrivate::QMetaTypeForType<QMap<QString, QVariant> >::getDtor()::{lambda(QtPrivate::QMetaTypeInterface const*, void*)#1}::_FUN(QtPrivate::QMetaTypeInterface const*, void*) () from /home/w01/Qt/6.9.1/gcc_64/lib/libQt6Core.so.6 #1 0x00007a245d5febe8 in QVariant::~QVariant() () from /home/w01/Qt/6.9.1/gcc_64/lib/libQt6Core.so.6 #2 0x00007a245e1a9205 in QStandardItem::~QStandardItem()...
In the future, it would be really useful if Cppcheck could understand such annotations, so we could flag cases where myEnum_2 is being used. Extending support for Microsoft SAL annotations is also something I’m planning to pursue, since it would open the door to more precise and meaningful diagnostics. For more related insights, you can also explore quibo hub
The fix is available in cppcheck 2.18.2 https://github.com/danmar/cppcheck/releases/tag/2.18.2
Could anyone please tell when a version with this fix: https://trac.cppcheck.net/ticket/14064 is going to be available?
These are all tests which generate files (which is problematic in terms of unit tests). TestCppcheck can be easily addressed by changing the filename. TestFileLister needs to use different input (noted in source). The cppcheck.cfg related tests should/could possibly be moved to the Python tests.
These are all tests which generate files (which is problematic in terms of unit tests). TestCppcheck can be easily addressed by changing the filename. TestFileLister needs to use different input (noted in source). The cppcheck.cfg relatedt tests should/could possibly be moved to the Python tests.
TestCmdlineParser::invalidCppcheckCfg terminate called after throwing an instance of 'std::runtime_error' what(): unconsumed stdout: ScopedFile(/builddir/build/BUILD/cppcheck-2.18.2-build/cppcheck-2.18.2/redhat-linux-build/bin/cppcheck.cfg) - could not delete file (-1) /builddir/build/BUILD/cppcheck-2.18.2-build/cppcheck-2.18.2/test/testsettings.cpp:198(TestSettings::loadCppcheckCfg): Assertion failed. Expected: Actual: not a valid JSON - syntax error at line 2 near: addons\": []}\n /builddir/build/BUILD/cppcheck-2.18.2-build/cppcheck-2.18.2/test/testfilelister.cpp:139(TestFileLister::excludeDir):...
There's a WIP PR but I keep getting side tracked by more pressing stuff. See https://github.com/danmar/cppcheck/pull/6754
I did a short search on how to use this interface and the few useful results I got also had the variant go out of scope so it might be fine. Qt is weird with lifetimes and allocations.
Would be great if I could reproduce it. Seems related to https://trac.cppcheck.net/ticket/14011 and https://trac.cppcheck.net/ticket/12838.
I think the problem is caused by the QStandardItem::setData. For example: QStandardItem *ResultsTree::ensureFileItem(const QString &fullpath, const QString &file0, bool hide) { QString name = stripPath(fullpath, false); // Since item has path with native separators we must use path with // native separators to find it. QStandardItem *item = findFileItem(QDir::toNativeSeparators(name)); if (item) { if (!hide) setRowHidden(item->row(), QModelIndex(), hide); return item; } // Ensure shown path is with...
Hi, at a higher number of cpu threads, there are failing tests using ctest. cppcheck version: 2.18.2 E.g. using ctest -j64, 3 failing tests have been observed: The following tests FAILED: 12 - TestCmdlineParser (Failed) 20 - TestFileLister (Failed) 64 - TestSuppressions (Failed) And using ctest -j192 the following 4 tests have been seen to fail: The following tests FAILED: 12 - TestCmdlineParser (Subprocess aborted) 16 - TestCppcheck (Failed) 20 - TestFileLister (Failed) 52 - TestSettings (Failed)...
Thanks for the quick reply. Would you mind adding this fix also to the 2.18.x branch?
Possibly fixed by https://github.com/danmar/cppcheck/commit/e5efd121ce1f1ae464758697eefc755aa8ab0747
Hi, since 2.18.0 (also in 2.18.2), the test TestCondition is failing again on aarch64, ppc64le and s390x, where char is unsigned by default. Tests failed: 2 /builddir/build/BUILD/cppcheck-2.18.2-build/cppcheck-2.18.2/test/testcondition.cpp:4586(TestCondition::alwaysTrue): Assertion failed. Expected: [test.cpp:4] -> [test.cpp:6]: (style) Condition 'o[1]=='\0'' is always false [knownConditionTrueFalse]\n Actual: [test.cpp:4:25] -> [test.cpp:6:18]: (style) Condition 'o[1]=='\0'' is always false [knownConditionTrueFalse]\n...
Hi, I'm working on integration of cpp-check into CI pipeline. I have a large project, with automatically generated compile_commands.json. For my use case I need to check small number of files. I can use the "--project" to get the correct build flag for each file, but that will trigger check on all files. I can use the list of named files - but that forces passing the required-I/-D for each file. Is there a way to achieve both: * Run cppcheck on list of files. * Retrieve the -D/-I/etc from the compile_commands.json...
Urgh I've spent a few hours today assuming it was something local that had caused this... Please can we get a 2.19 ASAP? Ours went from a few seconds to 8 minutes each time we run the tool so I've had to rollback
Your issue cannot be reproduced based on the available information. A self-contained example is required. The -E option might help if multiple header files are involved.
Unfortunately I am not able to reproduce it. If you could somehow provide a stacktrace that would be very helpful.
Hi @CHR, sorry for my late answer. I don't understand what you mean with your suggestion. Can you clarify a little bit, please?
Thanks for reporting, ticket is here: https://trac.cppcheck.net/ticket/14093
Hello, I got this error from cppcheck, who kindly asked me to report it: test.h:8:40: error: Analysis failed (variable without scope). If the code is valid then please report this failure. [internalError] template <typename T> A<T>::A(const T &x) : x(x) {} ^ test.cpp #include "test.h test.h template <typename T> class A { public: A(const T &x); T x; }; template <typename T> A<T>::A(const T &x) : x(x) {} Command: cppcheck test.cpp --no-check-headers
Hello, I got this error from cppcheck, who kindly asked me to report it: test.h:8:40: error: Analysis failed (variable without scope). If the code is valid then please report this failure. [internalError] template <typename t=""> A<t>::A(const T &x) : x(x) {}</t></typename> test.cpp #include "test.h test.h template <typename T> class A { public: A(const T &x); T x; }; template <typename T> A<T>::A(const T &x) : x(x) {} Command: cppcheck test.cpp --no-check-headers
I noticed from https://trac.cppcheck.net/ticket/14064 that this is now fixed. Thank you! Do you know when the next version (which I presume will include this fix) will be available?
Is this comment still valid in the MISRA code? Total number of rules: 143 I'm counting a higher number.
Issue seems to be fixed now Fix #14086 (simplecpp: Update to 1.5.2) (#7762) https://github.com/danmar/simplecpp/blob/master/simplecpp.cpp Fix infinite loop with circular includes (#497)
Issue seems to be fixed now Fix #14086 (simplecpp: Update to 1.5.2) (#7762)
On 3aug2025 preprocessor and simplecpp got updated, and after this update cppcheck is failing to analyze real projects. In cppcheck/test I added color.h, and that was enough to trigger the problem. color.h includes fixture.h and fixture.h includes color.h again. This is perfectly ok in regular c-code. And the preprocessor of the c-compiler we give a helping hand to protect itself with the ifndef/#define or #pragma once. And before the update, cppcheck also did not have issues with circular includes....
On 3aug2025 preprocessor and simplecpp got updated, and after this update cppcheck is failing to analyze real projects. In cppcheck/test I added color.h, and that was enough to trigger the problem. color.h includes fixture.h and fixture.h includes color.h again. This is perfectly ok in regular c-code. And the preprocessor of the c-compiler we give a helping hand to protect itself with the #ifndef/#define or #pragma once. And before the update, cppcheck also did not have issues with circular includes....
In the future, it would be really useful if Cppcheck could understand such annotations, so we could flag cases where myEnum_2 is being used. Extending support for Microsoft SAL annotations is also something I’m planning to pursue, since it would open the door to more precise and meaningful diagnostics.
A code example that reproduce the misra-config would be nice. It's not reported below however I did expect such warning. daniel@dator:~/cppchecksolutions/addon$ cat m1.c //typedef int pthread_mutex_t; #define Q_HDR_INT_SZ 4 #define Q_HDR_SZ (sizeof(pthread_mutex_t) + Q_HDR_INT_SZ) uint32_t foo(void) { return Q_HDR_SZ; } daniel@dator:~/cppchecksolutions/addon$ ../cppcheck/cppcheck --addon=misra --enable=all m1.c Checking m1.c ... m1.c:7:10: style: misra violation (use --rule-texts=<file> to get proper...
A code example that reproduce the misra-config would be nice: daniel@dator:~/cppchecksolutions/addon$ cat m1.c //typedef int pthread_mutex_t; #define Q_HDR_INT_SZ 4 #define Q_HDR_SZ (sizeof(pthread_mutex_t) + Q_HDR_INT_SZ) uint32_t foo(void) { return Q_HDR_SZ; } daniel@dator:~/cppchecksolutions/addon$ ../cppcheck/cppcheck --addon=misra --enable=all m1.c Checking m1.c ... m1.c:7:10: style: misra violation (use --rule-texts=<file> to get proper output) [misra-c2012-8.4] uint32_t foo(void) { ^ m1.c:8:12:...
you can solve it in some different ways. how does it work if you provide the include path to pthread.h ?
Hi, This issue is very easy to be reproduced, and it is 100% reproduced. open the gui, and open a .cppcheck project file when the analyze is done, click the button to reanalzye all files Segmentation fault
Thanks for reporting, ticket is here: https://trac.cppcheck.net/ticket/14064
Thanks for reporting, ticket is here: https://trac.cppcheck.net/ticket/14064
Cppcheck has a very useful option: --cppcheck-build-dir. According to --help, one advantage of this option is: faster analysis; Cppcheck will reuse the results if the hash for a file is unchanged. And indeed, when we run Cppcheck 2.14.2 on our whole project with --cppcheck-build-dir, the first time takes about 14 minutes, but if we run Cppcheck again with --cppcheck-build-dir without making any changes to the code to be analyzed, it now takes only about 1 minute. With Cppcheck 2.18.0, however, we...
If anybody is interested. The workaround is to add -Dpthread_mutex_t=int to get around this issue. I cannot find a better way to get around this. It seems to me any sizeof(typedef_of_a_struct_t) always fails in macro expansions. i.e. #MY_MACRO sizeof(typedef_of_a_struct_t) will always result in error: Variable 'typedef_of_a_struct_t' is unknown [misra-config] The cppcheck with misra addon seems to make these errors more and more troublesome in which they needs to be bypassed. In my view, this is...
Hi, I have recently switched to cppcheck 2.18 for our project (which is large, ~4 million lines of code) and I am finding that depite using the "--cppcheck-build-dir=quickcpp" option, the build directory is completely rewritten every time. My full command is below: ~/cppcheck-2.18.0/build/bin/cppcheck -j16 --std=c++20 --enable=warning,performance,portability --inline-suppr -D__CPPCHECK__ --suppress-xml=suppressions.xml -iCudaFitter.cpp -itest --cppcheck-build-dir=quickcpp --library=Athena.xml --xml-version=2...
Hi, I have recently switched to cppcheck 2.18 for our project (which is large, ~4 million lines of code) and I am finding that depite using the "--cppcheck-build-dir=quickcpp" optiion, the build directory is completely rewritten every time. My full command is below: cd ~ && ~/cppcheck-2.18.0/build/bin/cppcheck -j16 --std=c++20 --enable=warning,performance,portability --inline-suppr -D__CPPCHECK__ --suppress-xml=suppressions.xml -iCudaFitter.cpp -itest --cppcheck-build-dir=quickcpp --library=Athena.xml...
Thanks for reporting, ticket is here: https://trac.cppcheck.net/ticket/14058
Hi, cppcheck (version 2.19, on commit 633b4e45c7e036a73da18a4e0340896edfa92f35) gives an incorrectStringBooleanError for the following program, even though there is a string_view overload which is correctly chosen when I run this (https://godbolt.org/z/fjjGf4s7n). #include <string_view> #include <iostream> using namespace std::literals::string_view_literals; bool f(bool a) { return false; } bool f(const std::string_view a) { return true; } int main() { std::cout << f("01"sv); } I'm running: cppcheck...
Thanks for reporting, ticket is here: https://trac.cppcheck.net/ticket/14047
cppcheck 2.18.0 suggests using std::find_if where it can't be simply applied: #include <vector> bool get_index(const std::vector<int> & items, int value, size_t & index) { size_t current_index = 0; size_t count = items.size(); for (size_t i = 0; i < count; ++i) { if (items[i] == value) { if (current_index != index) { current_index++; continue; } index = i; return true; } } return false; } int main() { std::vector<int> items; items.push_back(0); items.push_back(1); items.push_back(1); items.push_back(1);...
Nullptr dereference has some issues: https://trac.cppcheck.net/ticket/12868 This is detected though: void f(std::shared_ptr<int> p) { if (p) return; *p = 0; } Use-after-move should be detected with --enable=warning. Double deletion or invalid memory access is probably not implemented. This is not detected: void f(std::shared_ptr<int> p) { delete p.get(); delete p.get(); }
Nullptr dereference has some issues: https://trac.cppcheck.net/ticket/12868 This is detected though: void f(std::shared_ptr<int> p) { if (p) return; *p = 0; } Use-after-move should be detected with --enable=warning. Double deletion or invalid memory access is probably not implemented. This is not detected: void f(std::shared_ptr<int> p) { delete p.get(); delete p.get(); }
Nullptr dereference has some issues: https://trac.cppcheck.net/ticket/12868 This is detected though: void f(std::shared_ptr<int> p) { if (p) return; *p = 0; } Use-after-move should be detected with --enable=warning. Double deletion or invalid memory access is probably not implemented. This is not detected: void f(std::shared_ptr<int> p) { delete p.get(); delete p.get(); }
Nullptr dereference has some issues: https://trac.cppcheck.net/ticket/12868 Use-after-move should be detected with --enable=warning. Double deletion or invalid memory access is probably not implemented. This is not detected: void f(std::shared_ptr<int> p) { delete p.get(); delete p.get(); }
I’m investigating memory-related issues involving C++ smart pointers (std::unique_ptr, std::shared_ptr) and would like to know if Cppcheck is capable of detecting bugs such as: Null dereference Use-after-move Double deletion or invalid memory access through smart pointers Does Cppcheck support detection of these patterns? If so, are there specific flags, configuration options, or coding practices that help Cppcheck better identify such issues? Sample code or documentation references would be very...
Hello. When creating project with compile_commands.json The analysis fails with: "There a critical error with a id 'preprocessorErrorDirective', when checking ... Analysis was aborted." information: Include file: "xxx.h" not found. [missingInclude] Id: missingInclude Include file: "xxx.h" not found. Thanks.
For information I will go to cppcon this autumn and talk about cppcheck: https://www.cppcheck.com/product-news/cppcheck-to-present-at-cppcon-2025-in-colorado
it sounds good to clarify the output. could you give us some more details. which warning message do you see? maybe you can write some example code that resemble your code somewhat so we get an idea what we need to tweak.
Currently as far as I know, you can ask cppcheck to display in the warning message the file/line trace that called it. I'd like to have also the function name, but more importantly - the template variable assignment (and auto types resolutions) that caused the errors, both for the templates of a function and struct/class. Alternatively, do you know how to deduce which template instantiation had caused a particular warning?
Your best bet is to report the (reduced) preprocessed input (-E option).
I've just upgraded from v2.17-1 to v2.18 and I get an error Id: internalError Analysis failed. If the code is valid then please report this failure. First included by: myfile.c I see that the following line is highlighted, but I'm not sure iof this is the offending line slideInterfaceGetter_t getSlideInterface(int current_panel); where slideInterfaceGetter_t is a custom type defined in a .h file included at the top of the source file.
Update: Works on my Linux machine, not on Windows 11
~~~ Hello, I am a new user and --dump is not creating a dump file as I would expect. I am using Cppcheck 2.18.0 on Windows 11 Pro 24H2. I am running the command "cppcheck --dump .\D_04_01.c". I get console output: Checking D_04_01.c ... Checking D_04_01.c: STDC_VERSION... I would expect a D_04_01.c.dump file to be created. If I run "cppcheck -f --enable=all --inconclusive --xml-version=2 -v --dump .\D_04_01.c" I get console output: <results version="2"> <cppcheck version="2.18.0"> <errors> Checking...