cppcheck Activity
Static source code analysis tool for C and C++ code
Brought to you by:
danielmarjamaki
Activity for cppcheck
-
Vit Kucera posted a comment on discussion General Discussion
Might be worth mentioning that if &c == &b is replaced with c < 0 && b > 0, it triggers: Logical conjunction always evaluates to false: c < 0 && b > 0. [incorrectLogicOperator]
-
CHR posted a comment on discussion General Discussion
Thanks for reporting, ticket is here: https://trac.cppcheck.net/ticket/14218
-
struct SomeStruct { SomeStruct(int a, int b) : a(a), b(b) {} int a, c[2]{0, 0}, b; }; [test.cpp:2]: (error) Member variable 'b' is initialized by itself. Tested with cppcheck-2.18.0
-
struct SomeStruct { SomeStruct(int a, int b) : a(a), b(b) {} int a, c[2]{0, 0}, b; }; [test.cpp:2]: (error) Member variable 'b' is initialized by itself.
-
Thomas Friedrichsmeier posted a comment on discussion General Discussion
Ah, I had not seen that ticket. I will point out, however, that we checks in that ticket are redundant, indeed, only the redundant check isNull() rather than isEmpty(). In my testcase, neither check is redundant. I also quite disagree with the ticket's (preliminary) conclusion to mark QString::isNull() as deprecated, however. Yes the Qt documentation states "historical reasons", and recommends avoid QString::isNull(), but no, it is neither deprecated upstream, nor is it useless. It can be put to...
-
See https://trac.cppcheck.net/ticket/12776
-
Cppcheck 2.18.3. Consider the following input file: #include <QString> int foo(const QString &in) { if (in.isNull()) { return 1; } else if (in.isEmpty()) { return 2; } return 3; } Running cppcheck --library=qt --enable=style test.cpp yields: Checking test.cpp ... test.cpp:6:26: style: Condition 'in.isEmpty()' is always false [knownConditionTrueFalse] } else if (in.isEmpty()) { ^ test.cpp:4:18: note: Assuming that condition 'in.isNull()' is not redundant if (in.isNull()) { ^ test.cpp:6:26: note: Condition...
-
James Bray posted a comment on discussion General Discussion
Hi, thanks for the suggestion. That does remove the error, but unfortunately a trivial change re-introduces it: void func( ) { char *text = strdup("test") if (!text) goto END; if (strcmp(text, "test")) goto END; if (text) free(text); return; END: } Replacing the "printf" with "goto END" in the strcmp conditional causes the nullPointerRedundantCheck to occur even with --check-level=exhaustive For the moment I will simply disable this warning.
-
Thanks for reporting, ticket is here: https://trac.cppcheck.net/ticket/14214 Maybe you can avoid the warning by adding --check-level=exhaustive to your command line.
-
Hi, I have the following code: void func( ) { char *text = strdup("test") if (!text) goto END; if (strcmp(text, "test")) printf("Different\n"); if (text) free(text); return; END: } When running using 2.18 or the latest code from 17-Oct-25, I get the following spurious warnings: test.c:6:15: warning: Either the condition 'text' is redundant or there is possible null pointer dereference: text. [nullPointerRedundantCheck] if (strcmp(text, "test")) ^ test.c:9:8: note: Assuming that condition 'text' is...
-
Andrew C Aitchison posted a comment on discussion General Discussion
In that case it is definitely a bug in addons/threadsafety.py I note that cppcheck --enable=warning --addon=y2038.py test/main.c gives similar false positives. I copied this feature from y2038.py to threadsafety.py but I don't think my python is up to fixing this.
-
The original code does not reference ctime() at all.
-
On Ubuntu 25-04 (Plucky) man ctime says (in the attributes table): Interface Attribute Value ctime() Thread safety MT-Unsafe race:tmbuf race:asctime env locale (see man 7 attributes for the detaiila of the terms used). so this is an edge case, but it is not obvious to me that it is a false-positive - what do others think ? Background The list of MT-unsafe functions in the threadsafety addon is computer-generated by tools/MT-Unsafe.py which reads the attributes table of man pages. We could ignore...
-
I see, didn't realize that this addon existed.
-
Nikita Leontiev posted a comment on discussion General Discussion
I used open source cppcheck 2.18.0 with --addon=threadsafety.py arg.
-
threadsafety-unsafe-call seems to be a cppcheck Premium feature, so you should report the bug here: https://www.cppcheck.com/
-
David Gibson posted a comment on discussion General Discussion
I'm aware that's a weird use of -include. The difficulty was that to trigger the bug I needed to really include that specific header - not use cppcheck's built in knowledge of standard headers. But using -I would cause it to really process all the other headers too, which I didn't want to do, and those headers triggered some additional spurious warnings that aren't relevant to this case. -include was a workaround to accomplish that. Just including the structure definition inline was a better approach,...
-
cppcheck 2.18.0 generates threadsafety-unsafe-call false positive for the following code: struct Object { int ctime; }; int main() { Object obj; obj.ctime = 0; return 0; } test\main.cpp:3:6: warning: ctime is MT-unsafe [threadsafety-unsafe-call] int ctime; ^ test\main.cpp:9:6: warning: ctime is MT-unsafe [threadsafety-unsafe-call] obj.ctime = 0; ^
-
cppcheck 2.18.0 generates misra-c2012-12.3 false positive for the following code: class A { }; class B { }; class C : public A, public B { }; test\main.cpp:9:19: style: The comma operator should not be used [misra-c2012-12.3] class C : public A, public B ^
-
Thanks for reporting, ticket is here: https://trac.cppcheck.net/ticket/14193
-
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;...
-
Oliver Stöneberg posted a comment on discussion General Discussion
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
-
Tobias Markus posted a comment on discussion General Discussion
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;...
-
Félix-Antoine Constantin posted a comment on discussion General Discussion
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...
-
Volodymyr posted a comment on discussion General Discussion
[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
-
Jan Joseph modified a comment on discussion General Discussion
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.
-
Gwyn Ciesla posted a comment on discussion General Discussion
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.
-
Boris Blokland posted a comment on discussion General Discussion
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......
-
Reshma V Kumar posted a comment on discussion Development
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.
-
john borland posted a comment on discussion Development
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...
-
Joel Shuman modified a comment on discussion General Discussion
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.
-
Bassam Abdul-Baki modified a comment on discussion General Discussion
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:...
-
Dave Wichers posted a comment on discussion Development
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...
-
Yannick HOUDOT posted a comment on discussion General Discussion
#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 ?
-
Dave Ohlsson posted a comment on discussion Development
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==...
-
wy163 modified a comment on discussion General Discussion
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()...
-
debra modified a comment on discussion General Discussion
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
1 >
