Thanks for reporting, ticket is here: https://trac.cppcheck.net/ticket/14192
cppcheck 2.18.0 generates unreadVariable false positive for the following code: #include <inttypes.h> #include <stdio.h> void func() { bool flag = false; for (uint8_t i = 0; i < 10; ++i) { if (i % 2 == 0) flag = true; else flag = false; if (flag) printf("\n"); } } test\main.cpp:6:12: style: Variable 'flag' is assigned a value that is never used. [unreadVariable] bool flag = false; ^ unreadVariable doesn't appear on slightly modified code: void func() { bool flag = false; for (uint8_t i = 0; i < 10;...
FYI -include is to always include into a file which is probably not what you want - see https://gcc.gnu.org/onlinedocs/gcc-15.2.0/gcc/Preprocessor-Options.html#index-include. This is usually used for something like precompiled headers.
Thanks for reporting, ticket is here: https://trac.cppcheck.net/ticket/14191
How about this? void f(std::set<int>& s, int i) { auto [_, b] = s.insert(i); if (b) { dostuff(); } }
Thanks for reporting, ticket is here: https://trac.cppcheck.net/ticket/14189
Again, this is the perfetto source code from https://github.com/google/perfetto src/protozero/filtering/filter_util.cc:328:28: performance: Searching before insertion is not necessary. [stlFindInsert] seen_msgs.insert(nested_type); The code is as follows: if (seen_msgs.find(nested_type) == seen_msgs.end()) { seen_msgs.insert(nested_type); queue.emplace_back(result.nested_msg_index, nested_type); } While I can understand the reason for the warning, the emplace_back command does depend on it, so the...
I'm currently running cppcheck on Google's perfetto source code. See https://github.com/google/perfetto Here's part of the source code where it gives me a potential performance info: LlvmSymbolizerImpl::LlvmSymbolizerImpl() { llvm::symbolize::LLVMSymbolizer::Options opts; opts.UseSymbolTable = true; opts.Demangle = true; opts.PrintFunctions = llvm::symbolize::FunctionNameKind::LinkageName; opts.RelativeAddresses = false; opts.UntagAddresses = true; #if LLVM_VERSION_MAJOR >= 12 opts.UseDIA = false;...
I'm currently running cppcheck on Google's perfetto source code. See https://github.com/google/perfetto Here's part of the source code where it gives me a potential performance info: LlvmSymbolizerImpl::LlvmSymbolizerImpl() { llvm::symbolize::LLVMSymbolizer::Options opts; opts.UseSymbolTable = true; opts.Demangle = true; opts.PrintFunctions = llvm::symbolize::FunctionNameKind::LinkageName; opts.RelativeAddresses = false; opts.UntagAddresses = true; #if LLVM_VERSION_MAJOR >= 12 opts.UseDIA = false;...
Sorry, it took me a while to look at this again. Here's the revised source including the struct definition. $ cppcheck --enable=all --library=posix --suppress=missingIncludeSystem --suppress=unusedStructMember --suppress=unusedFunction cppcheck-getsockopt-uninitvar.c Checking cppcheck-getsockopt-uninitvar.c ... cppcheck-getsockopt-uninitvar.c:111:2: warning: Assignment of function parameter has no effect outside the function. Did you forget dereferencing it? [uselessAssignmentPtrArg] tinfo = &tinfo_new;...
The following code will generate a false positive for knownConditionTrueFalse with cppcheck 2.18 #include <vector> void foo(const std::vector<int> &bar) { for(const int &b : bar) { for(const int &c : bar) { if (&c == &b) continue; } } } cppcheck --enable=style test.cpp test.cpp:9:14: style: The comparison '&c == &b' is always true because '&c' and '&b' represent the same value. [knownConditionTrueFalse] if (&c == &b) ^ test.cpp:7:24: note: 'c' is assigned value 'bar' here. for(const int &c : bar)...
Running cppcheck cppcheck --enable=style test.cpp on the following code snippet will result in an error . using IntPtr = int *; int* foo(IntPtr bar) { return bar = 0; } test.cpp:3:17: style: Parameter 'bar' can be declared as pointer to const [constParameterPointer] The problem is that since the type is defined through using (the same behaviour would be observed if I was using typedef), it is not possible to add const here, since it will result in the underlying type int *const rather than const...
[image: изображение.png] The problem is that it doesn't display errors. And this message repeats itself. I thought it was a problem with the code, but no, it's the same with another one (I have the latest version and I'm doing it through code::block). I also tried through the console, but it's the same for me. <results version="2"> <cppcheck version="2.18.0"> <errors> <error id="user-content-checkersReport" severity="information" msg="Active checkers: 169/966 (use --checkers-report=<filename>...
Thanks for reporting, ticket is here: https://trac.cppcheck.net/ticket/14181
Sorry, I forgot to mention the CLI command cppcheck --enable=all \ --inconclusive \ --std=c99 \ --addon=misra.json \ --language=c \ --platform=native \ --inline-suppr \ --verbose \ --check-level=exhaustive \ --project=compile_commands.json \ --suppressions-list=suppressions.txt \ --xml --xml-version=2 with misra.json being { "script": "./misra.py", "args": [ "--rule-texts=./misra.txt" ] } Since the actual file structure is a bit complicated I tried to reproduce the behaviour in a pseudo code. file_A.h...
Sorry, I forgot to mention the CLI command cppcheck --enable=all \ --inconclusive \ --std=c99 \ --addon=misra.json \ --language=c \ --platform=native \ --inline-suppr \ --verbose \ --check-level=exhaustive \ --project=compile_commands.json \ --suppressions-list=suppressions.txt \ --xml --xml-version=2 with misra.json being { "script": "./misra.py", "args": [ "--rule-texts=./misra.txt" ] } Since the actual file structure is a bit complicated I tried to reproduce the behaviour in a pseudo code. file_A.h...
Using cppcheck 2.18, the following code snippet will raise nullPointerRedundantCheck even if it shouldn't. #include <stdlib.h> [[noreturn]] void bar(const char *format, ...) __attribute__((format(printf, 1, 2))); int foo(char* location) { if (location == nullptr) { bar(""); } return strtol(location, nullptr, 10); } cppcheck --enable=warning test.cpp test.cpp:13:16: warning: Either the condition 'location==nullptr' is redundant or there is possible null pointer dereference: location. [nullPointerRedundantCheck]...
Cppcheck is triggering 5.8 for struct member with the same name as external identifier in a erratic manner (sometimes it throws the error, sometimes it doesn't) struct A { int size; }; extern struct B size; Since the vars are in different namespaces this should be MISRA 5.8 compliant.
Thank you!
Thanks for reporting, ticket is here: https://trac.cppcheck.net/ticket/14171
Please include the struct definition that reproduces the error.
It does not. It does appear if I replace the --include with -I /usr/include so cppcheck can find the header that way. That also triggers a bunch of other warnings from headers, though. The warning also appears if I don't include that header, but locally define struct tcp_info. The bug originally appeared that way, but it's a large structure, so I used the header for brevity, The warning does not appear if I use the version of the structure defined in /usr/include/netinet/tcp.h instead of the one...
It does not. It does appear if I replace the --include with -I /usr/include so cppcheck can find the header that way. The second approach also triggers a bunch of other warnings from headers, though. The warning also appears if I don't include that header, but locally define struct tcp_info. The bug originally appeared that way, but it's a large structure, so I used the header for brevity, The warning does not appear if I use the version of the structure defined in /usr/include/netinet/tcp.h instead...
I just encountered an odd false positive on uninitvar. cppcheck is detecting an variable as uninitialized, although it has been set as the result of a getsockopt(). Specifically, with the attached example file: $ cppcheck --enable=all --library=posix --suppress=missingIncludeSystem --suppress=unusedStructMember --suppress=unusedFunction --include=/usr/include/linux/tcp.h cppcheck-getsockopt-uninitvar.c Checking cppcheck-getsockopt-uninitvar.c ... Checking cppcheck-getsockopt-uninitvar.c: __BIG_ENDIAN_BITFIELD......
I just encountered an odd false positive on uninitvar. cppcheck is detecting an variable as uninitialized, although it has been set as the result of a getsockopt(). Specifically, with the attached example file: $ cppcheck --enable=all --library=posix --suppress=missingIncludeSystem --suppress=unusedStructMember --suppress=unusedFunction --include=/usr/include/linux/tcp.h cppcheck-getsockopt-uninitvar.c Checking cppcheck-getsockopt-uninitvar.c ... Checking cppcheck-getsockopt-uninitvar.c: __BIG_ENDIAN_BITFIELD......
It does not. It does appear if I replace the --include with -I /usr/include so cppcheck can find the header that way. The second approach also triggers a bunch of other warnings from headers, though. The warning also appears if I don't include that header, but locally define struct tcp_info. The bug originally appeared that way, but it's a large structure, so I used the header for brevity,
It does not. It does appear if I replace the --include with -I /usr/include so cppcheck can find the header that way. The second approach also triggers a bunch of other warnings from headers, though.
From: https://bugzilla.redhat.com/show_bug.cgi?id=2400880 filter.c:71:7: error: Return value of allocation function 'freopen' is not stored. [leakReturnValNotUsed] if (freopen(NULL, "w+b", imf) == NULL) die( errno, LOC ); Since freopen() returns either imf or NULL, cppcheck should accept this line of code. This error report is probably the result of some general logic from which freopen() should be exempted.
Well, 2.18 is current, so you might consider updating.
Cppcheck 2.13.0
Which version do you use? I'm unable to reproduce this with current head.
typedef struct { uint8_t var1; uint8_t var2; uint8_t var3; uint8_t var4; } Foo; constexpr uint8_t var2 = 2; constexpr uint8_t var3 = 3; Foo foo { .var2 = var2, // <- false positive .var3 = var3 };
Does this happen without --include=/usr/include/linux/tcp.h?
Sorry, forgot to mention, this occurred with cppcheck 2.18.3 (installed from Fedora package cppcheck-2.18.3-1.fc42.x86_64).
I just encountered an odd false positive on uninitvar. cppcheck is detecting an variable as uninitialized, although it has been set as the result of a getsockopt(). Specifically, with the attached example file: $ cppcheck --enable=all --library=posix --suppress=missingIncludeSystem --suppress=unusedStructMember --suppress=unusedFunction --include=/usr/include/linux/tcp.h cppcheck-getsockopt-uninitvar.c Checking cppcheck-getsockopt-uninitvar.c ... Checking cppcheck-getsockopt-uninitvar.c: __BIG_ENDIAN_BITFIELD......
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