cppcheck Activity
Static source code analysis tool for C and C++ code
Brought to you by:
danielmarjamaki
Activity for cppcheck
-
CHR posted a comment on discussion General Discussion
I didn't quite understand the solution of the OP. "A quick solution that wasn't immediately obvious to us was to move all our external libraries to an external directory and updating our include paths accordingly" The idea is to not let cppcheck see the Eigen headers.
-
hardork posted a comment on discussion General Discussion
Hello, sorry to move back that topic. I encounter the same issue with the usage of the eigen library. include/eigen/src/plugins/CommonCwiseBinaryOps.h:19]: (error) syntax error It's exactly the same issue on operator- or operator+ or any sign after operator. I didn't manage to create an eigen.cfg that works. Don't know how to make it work. I try to do <define name="EIGEN_MAKE_CWISE_BINARY_OP(operator-,OPNAME)" value=""> It works with a simple sample of code, but don't work with CommonCwiseBinaryOps.h...
-
AlexHsieh posted a comment on discussion General Discussion
Thank you for confirming.
-
Thanks for reporting, ticket is here: https://trac.cppcheck.net/ticket/14302
-
Using cppcheck 2.18.0 to check this code: struct ST { unsigned char a[1]; }; void f(){ ST st; sscanf("1", "%hhu", st.a); } got this warning: test.cpp:6:5: warning: %hhu in format string (no. 1) requires 'unsigned char *' but the argument type is 'const char *'. [invalidScanfArgType_int] sscanf("1", "%hhu", st.a); ^ Is this a false positive warning?
-
Thanks for reporting, ticket is here: https://trac.cppcheck.net/ticket/14300
-
Nikita Leontiev posted a comment on discussion General Discussion
cppcheck 2.18.0 generates duplicateValueTernary false positive for the following code: class Base { }; class A : public Base { }; class B : public Base { }; int main(int argc, const char *[]) { A *a = new A(); B *b = new B(); Base *p = argc?static_cast<Base*>(a):static_cast<Base*>(b); (void)(p); delete a; delete b; return 0; } test\main.cpp:17:38: style: Same value in both branches of ternary operator. [duplicateValueTernary] Base *p = argc?static_cast<Base*>(a):static_cast<Base*>(b); ^ No false...
-
Daniel Marjamäki posted a comment on discussion Development
Since it seems there will be no fixes for the issues introduced by https://github.com/danmar/cppcheck/pull/7658 it needs to be reverted before release (I will post a PR if nothing happens until the end of the week). I guess we can revert it and then the changes can be polished and broken up and resubmitted. We also need to land https://github.com/danmar/cppcheck/pull/7962 - I still want those changes to be cleaner though. It's still a draft PR. Do I understand correctly that compilation and linking...
-
Thanks for reporting, ticket is here: https://trac.cppcheck.net/ticket/14296
-
Marcin Pytel posted a comment on discussion General Discussion
I'm using cppcheck 2.18. This is code: struct S { int i; }; enum { ZERO, ONE, TWO, THREE, FOUR, FIVE }; struct S arr[] = { [ZERO] = {}, [ONE] = {}, [TWO] = {}, [THREE] = {}, [FOUR] = {}, [FIVE] = {}, [FIVE + 1] = {}, [FIVE + 2] = {}, [FIVE + 3] = {} }; void foo() { struct S *s; _Static_assert(sizeof(arr) / sizeof(*arr) == 9, "assert 1"); _Static_assert(FIVE == 5, "assert 2"); for (int i = 0; i < FIVE + 3; i++) { s = &arr[i]; } } When running cppcheck the output is: error: Array 'arr[6]' accessed...
-
I'm using cppcheck 2.18. This is piece of code: void foo() { extern int i; } int i; When running cppcheck --enable=style the output is: style: Local variable 'i' shadows outer variable [shadowVariable]
-
Feel free to create a PR. I will not do any more active work on misra.py.. but will be happy to review/merge PRs that fix misra.py bugs. We provide better Misra checking in Cppcheck Premium.
-
Please open a PR containing your patches.
-
Reshma V Kumar posted a comment on discussion Development
Could any of the maintainers look into this and let me know your suggestions?
-
Peter Schops posted a comment on discussion Development
when you have the following in the code, the misra check crashes in the misra_20_9 check #define bad_define #define correct_define 1 #if bad_define printf ("will crash the misra check\n"); #endif #if correct_define printf ("Hello\n"); #endif I managed to fix the code by adding an extra escape in misra.py. This way we don't try to access s[0] after the cond.E.split def misra_20_9(self, cfg): for cond in cfg.preprocessor_if_conditions: if cond.E is (None or u""): continue I found it also strange that...
-
No repro with head, probably fixed by https://github.com/danmar/cppcheck/pull/7521
-
Nicholas Dedekind modified a comment on discussion Development
Use of a structured binding in an if statement initializer is an automatic violation of the variableScope rule. The scope of entry is already at the if statement, so it can't actually be reduced futher (unless it's counting the if condition clause itself). It doesn't make much sense in the usage though. #include <map> int main() { std::map<int,int> m; if (auto&& [entry, inserted] = m.emplace(1,2); inserted) { return entry->second; } return 0; } test.cpp:6:14: style: The scope of the variable 'entry'...
-
Use of a structured binding in an if statement initializer is an automatic violation of the variableScope rule. The scope of entry is already at the if statement, so it can't actually be reduced futher (unless it's counting the if condition clause itself. It doesn't make much sense in the usage though. #include <map> int main() { std::map<int,int> m; if (auto&& [entry, inserted] = m.emplace(1,2); inserted) { return entry->second; } return 0; } test.cpp:6:14: style: The scope of the variable 'entry'...
-
Use of a structured binding in an if statement initializer is an automatic violation of the variableScope rule. While strictly the scope can be reduced, I don't think it makes sense since entry cannot be used outside of the if scope and the cppcheck rule requires disabling on every instance. We should at least have a specific option to disable these cases. #include <map> int main() { std::map<int,int> m; if (auto&& [entry, inserted] = m.emplace(1,2); inserted) { return entry->second; } return 0;...
-
Teraslilja posted a comment on discussion General Discussion
Operating environment: cppcheck compiled at WSL (Ubuntu 22.04.5 LTS), while repository is located at Windows 11 partition. If a header is included as #include "Header.hpp" and #include "header.hpp" (mixed cases of letters), it is happily compiled with Visual Studio. However, if cppcheck is run (at WSL/Ubuntu), a "syntaxError" is generated (for each different header name), when enumerated class type is defined. Most likely cppcheck thinks that "Header.hpp" and "header.hpp" are different files. Maybe...
-
This is tracked here: https://trac.cppcheck.net/ticket/10616
-
Ruth Brown posted a comment on discussion General Discussion
==> claim <== style: Return value '++energy_!=0' is always true [knownConditionTrueFalse] bool Racer::rest() { return ++energy_ != 0; } ==> rebuttal <== Incrementing the maximum size_t always wraps around to 0. #include <iostream> #include <cstddef> #include <limits> int main() { size_t x = std::numeric_limits<size_t>::max(); x++; std::cout << x << "\n"; // prints 0 }
-
Thanks for reporting, ticket is here: https://trac.cppcheck.net/ticket/14279
-
Thanks for reporting, ticket is here: https://trac.cppcheck.net/ticket/14278
-
Thanks for reporting, ticket is here: https://trac.cppcheck.net/ticket/14278
-
Thanks for reporting, ticket is here: https://trac.cppcheck.net/ticket/14279
-
cppcheck 2.18.0 generates invalidPrintfArgType_sint and invalidPrintfArgType_float false positives for the following code: #include <assert.h> #include <stdio.h> class Object { private: int m_i; double m_d; public: Object(int i, double d) : m_i(i), m_d(d) {} template<typename T> T get() { assert(false); return T(); } template<> int get() { return m_i; } template<> double get() { return m_d; } }; int main() { Object obj(1, 1.5); printf("%d, %f\n", obj.get<int>(), obj.get<double>()); return 0; } test\main.cpp:33:2:...
-
cppcheck 2.18.0 generates functionStatic false positive for the following code: #include <assert.h> class Object { private: int m_i; double m_d; public: Object(int i, double d) : m_i(i), m_d(d) {} template<typename T> T get() const { assert(false); return T(); } template<> int get() const { return m_i; } template<> double get() const { return m_d; } }; test\main.cpp:12:4: performance: inconclusive: Technically the member function 'Object::get' can be static (but you may consider moving to unnamed...
-
Oliver Stöneberg posted a comment on discussion Development
Since it seems there will be no fixes for the issues introduced by https://github.com/danmar/cppcheck/pull/7658 it needs to be reverted before release (I will post a PR if nothing happens until the end of the week). We also need to land https://github.com/danmar/cppcheck/pull/7962 - I still want those changes to be cleaner though. https://github.com/danmar/simplecpp/issues/583 also needs to be fixed (I am waiting for feedback on the initial work). So does https://github.com/danmar/simplecpp/issues/556...
-
I am not sure if that will be fixed soon. I know what to change but there is some logic which needs to be tested and gives me headaches. I am fixing everything around it though.
-
I am not sure if that will be fixed soon. I know what to change but there is some logic which needs to be tested and gives me headaches. I amfixing evertyhing around it though.
-
ok looks like firewave is on it already so we can wait a little..
-
ok looks like firewave is on it so we can wait a little..
-
We should probably fix this first: https://trac.cppcheck.net/ticket/14268 / https://github.com/danmar/simplecpp/issues/589
-
is it ok to release this weekend? I feel there are no specific tickets we must solve.
-
Thanks for reporting, ticket is here: https://trac.cppcheck.net/ticket/14267
-
Karen Huang modified a comment on discussion General Discussion
The MSVC team regularly builds popular open-source projects, including yours, with development versions of the build tools in order to find and fix regressions in the compiler and libraries before they can ship and cause trouble for the world. This also allows us to provide advance notice of breaking changes, which is the case here. cppcheck failed to build with /std:c++latest option on Windows with MSVC. Could you please help to take a look? Thank you! Repro steps: 1. Open VS 2022 x64 CMD. 2. git...
-
The MSVC team regularly builds popular open-source projects, including yours, with development versions of the build tools in order to find and fix regressions in the compiler and libraries before they can ship and cause trouble for the world. This also allows us to provide advance notice of breaking changes, which is the case here. cppcheck failed to build with /std:c++latest option on Windows with MSVC. Could you please help to take a look? Thank you! Repro steps: 1. Open VS 2022 x64 CMD. 2. git...
-
The MSVC team regularly builds popular open-source projects, including yours, with development versions of the build tools in order to find and fix regressions in the compiler and libraries before they can ship and cause trouble for the world. This also allows us to provide advance notice of breaking changes, which is the case here. cppcheck failed to build with /std:c++latest option on Windows with MSVC. Could you please help to take a look? Thank you! Repro steps: 1. Open VS 2022 x64 CMD. 2. git...
-
The MSVC team regularly builds popular open-source projects, including yours, with development versions of the build tools in order to find and fix regressions in the compiler and libraries before they can ship and cause trouble for the world. This also allows us to provide advance notice of breaking changes, which is the case here. cppcheck failed to build with /std:c++latest option on Windows with MSVC. Could you please help to take a look? Thank you! Repro steps: 1. Open VS 2022 x64 CMD. 2. git...
-
Matthew Markland posted a comment on discussion General Discussion
I don't have a 4-byte type I can use in a #define to do the mapping. The compiler is truly supplying another base integral type with a sizeof(4) that I need to have cppcheck recognize in a way where it does all of its checking, unlike <podtype>. Other scanners I've used allow for the definition of extensions like this, but I can understand if it is not part of the design of cppcheck. We have come up with a very kludgy workaround using a mixture of the platform file and some defines, but we were hoping...
-
Creating a .cfg file with the necessary defines is probably the way to go.
-
I see the related ticket has been closed due to it being a Windows compatibility situation. My situation is not that. Should I reopen the existing ticket or open a new one?
-
Thanks for reporting, ticket is here: https://trac.cppcheck.net/ticket/14256
-
zzattack posted a comment on discussion Development
This gives a syntax error in cppcheck 2.18: getMainQueue().queueAction([self=shared_from_this(), x, y] mutable { handle(x, y); }); I believe it even leads to failure to parse any lines that come after, and breaks analysis of anything including a file with this construct. Adding parentheses between the captures list and mutable keyword solves it: getMainQueue().queueAction([self=shared_from_this(), x, y] () mutable { handle(x, y); });
-
I neglected to supply a key piece of information; on the platform/compiler in question sizeof(__int32) != sizeof(int) so the suggestion of using the #define is a good one and would work in most cases, it doesn't work here. Matt Markland
-
Related ticket: https://trac.cppcheck.net/ticket/14245
-
Andrew C Aitchison posted a comment on discussion General Discussion
What happens if you have #define __int32 int ?
-
In my recent experiments with cppcheck it appears that it expects to find the library and platform files passed via the --library and --platform options in a well-known path derived from the location of the executable. Is there any interest in making these options accept a fully-qualified path? In my situation I don't have access to the cfg or platform directories in the cppcheck install so I have issues experimenting with platform and library files unless I build it myself and run in my own local...
-
I'm working on a code base which uses a compiler that has a basic type __int32 which is equivalent to an int on most platforms (i.e. 4-byte type). This type can be used where int can be used so you can have things like typedef unsigned __int32 uint32; This causes problems because cppcheck views this as declaring a variable named __int32 of type unsigned and the AST parsing blows up. Is there an extension point in cppcheck where I can teach it about new basic types? I know there is the podtype construct...
-
Thanks! A friend created this ticket: https://trac.cppcheck.net/ticket/14252 We should fix Cppcheck. But you can workaround these false positives if you make your code consistent. To avoid the false positive you can explicitly specify or drop specification of the template parameter for both declaration and definition. It should not missmatch. Either use matrix<FLOAT> or just matrix in both declaration and definition.
-
here is a GUI test report (using a recent release-windows nightly build). Version V 2.19 PASS 89 FAIL 17 NOT SURE 6 Total Test Cases 112
-
here is a GUI test report. Version V 2.19 PASS 89 FAIL 17 NOT SURE 6 Total Test Cases 112
-
here is a GUI test report.
-
Jaroslav Fojtik modified a comment on discussion Development
I have noted false positive: data=NULL; resize(m.size1D,m.size2D); if(data==NULL) {size1D=size2D=0;return;} ** "Condition data==NULL is always true"** CppCheck misses a template function resize that sets data to non NULL. //this method allocates a new data structure with a given size template <class FLOAT> void matrix<FLOAT>::resize(TSIZE x, TSIZE y) { ......... if((data=(FLOAT **)calloc(y,sizeof(FLOAT *))) == NULL) //pointers to rows { size2D=size1D=0; //allocation error RaiseError(MatrixId|No_Memory,this);...
-
-
I have noted false positive: data=NULL; resize(m.size1D,m.size2D); if(data==NULL) {size1D=size2D=0;return;} ** "Condition data==NULL is always true"** CppCheck misses a template function resize that sets data to non NULL. //this method allocates a new data structure with a given size template <class FLOAT> void matrix<FLOAT>::resize(TSIZE x, TSIZE y) { ......... if((data=(FLOAT **)calloc(y,sizeof(FLOAT *))) == NULL) //pointers to rows { size2D=size1D=0; //allocation error RaiseError(MatrixId|No_Memory,this);...
-
I have noted false positive: *data=NULL; resize(m.size1D,m.size2D); if(data==NULL) {size1D=size2D=0;return;} ** "Condition data==NULL is always true"** CppCheck misses a template function resize that sets data to non NULL. //this method allocates a new data structure with a given size template <class FLOAT> void matrix<FLOAT>::resize(TSIZE x, TSIZE y) { ......... if((data=(FLOAT **)calloc(y,sizeof(FLOAT *))) == NULL) //pointers to rows { size2D=size1D=0; //allocation error RaiseError(MatrixId|No_Memory,this);...
-
I have noted false positive: *data=NULL; resize(m.size1D,m.size2D); if(data==NULL) {size1D=size2D=0;return;}* ** "Condition data==NULL is always true"** CppCheck misses a template function resize that sets data to non NULL. //this method allocates a new data structure with a given size template <class FLOAT> void matrix<FLOAT>::resize(TSIZE x, TSIZE y) { ......... if((data=(FLOAT **)calloc(y,sizeof(FLOAT *))) == NULL) //pointers to rows { size2D=size1D=0; //allocation error RaiseError(MatrixId|No_Memory,this);...
-
I have noted false positive: data=NULL; resize(m.size1D,m.size2D); if(data==NULL) {size1D=size2D=0;return;} ** "Condition data==NULL is always true"** CppCheck misses a template function resize that sets data to non NULL. //this method allocates a new data structure with a given size template <class FLOAT> void matrix<FLOAT>::resize(TSIZE x, TSIZE y) { ......... if((data=(FLOAT **)calloc(y,sizeof(FLOAT *))) == NULL) //pointers to rows { size2D=size1D=0; //allocation error RaiseError(MatrixId|No_Memory,this);...
-
Vit Kucera posted a comment on discussion General Discussion
Thanks for checking.
-
It seems that false positive is already fixed. daniel@dator:~/cppcheck$ ../.cppcheck/cppcheck-2.18.0 --enable=style 1.cpp Checking 1.cpp ... 1.cpp:7:17: warning: Logical conjunction always evaluates to false: c < 0 && b > 0. [incorrectLogicOperator] if (c < 0 && b > 0) ^ 1.cpp:5:24: note: 'c' is assigned value 'bar' here. for(const int &c : bar) ^ 1.cpp:3:22: note: 'b' is assigned value 'bar' here. for(const int &b : bar) ^ 1.cpp:7:17: note: Logical conjunction always evaluates to false: c < 0 &&...
-
I would like that such tickets are fixed also. If you know a suitable person that could fix those for a fixed price let me know. I have no time to look at it. Tweaking the build scripts does not rule out that C++ code is tweaked and vice versa.
-
Most of the selfcheck time seems to be spent on cmdlineparser.cpp, where we burn a lot of cycles unproductively. See https://trac.cppcheck.net/ticket/10765 and https://trac.cppcheck.net/ticket/11262 If we could fix the underlying issues, that would probably give a much bigger speedup than changing the compiler.
-
Most of the selfcheck time seems to be spent on cmdlineparser.cpp, where we burn a lot of cycles unproductively. See https://trac.cppcheck.net/ticket/10765 and https://trac.cppcheck.net/ticket/11262
-
For me, a basic selfcheck takes ~10 times longer time in windows than in linux. Switching to mingw makes it better but it's still much slower. Maybe something more can be done? Command: cd path/to/cppcheck cppcheck -D__GNUC__ -D__CPPCHECK__ lib
-
For me, a selfcheck takes ~10 times longer time in windows than in linux. Switching to mingw makes it better but it's still much slower. Maybe something more can be done?
-
I have discovered that cppcheck compiled with mingw is drastically faster than cppcheck compiled with visual studio. I see that mingw builds are ~3 times faster on several machines. You can compare yourself using the artifacts from release-windows and release-windows-mingw actions. therefore I believe we should move from visual studio to mingw for the windows release build in the future. However firewave has warned that we are not ready for such a switch yet.
-
I would like to release Cppcheck 2.19 in couple of weeks. Please suggest critical bugs that we need to focus on during the coming weeks. daca crashes looks "acceptable" right now. There are two crashes with HEAD but we had those with 2.18 also. http://cppcheck1.osuosl.org:8000/crash.html
-
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]
-
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...
-
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.
-
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;...
-
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;...
1 >