cppcheck Activity
Static source code analysis tool for C and C++ code
Brought to you by:
danielmarjamaki
Activity for cppcheck
-
Christoph posted a comment on discussion General Discussion
Hello, I tried to update openSuse's cppcheck package to version 2.19. RPM lint complains that cppcheck.x86_64: E: binary-or-shlib-defines-rpath (Badness: 10000) /usr/bin/cppcheck (RUNPATH: /home/abuild/rpmbuild/BUILD/cppcheck-2.19.0-build/cppcheck-2.19.0/build/lib:) cppcheck-gui.x86_64: E: binary-or-shlib-defines-rpath (Badness: 10000) /usr/bin/cppcheck-gui (RUNPATH: /home/abuild/rpmbuild/BUILD/cppcheck-2.19.0-build/cppcheck-2.19.0/build/lib:) The binary or shared library defines RPATH' (orRUNPATH')...
-
CHR posted a comment on discussion Development
Unfortunately we haven't been able to test 32-bit builds in our CI for a while now. Those tests indeed fail on a 32-bit platform.
-
Moritz Haase posted a comment on discussion Development
Hi, I'm observing three different test failures while trying to upgrade Alpine Linux's cppcheck package from 2.18.3 to 2.19.0. Only the 32-bit platforms (x86, armv7, armhf) are affected. test/testcondition.cpp:2638(TestCondition::oppositeInnerConditionEmpty) test/test64bit.cpp:107(Test64BitPortability::functionpar) test/test64bit.cpp:258(Test64BitPortability::returnIssues) Full output of the failing assertions is: [...]/cppcheck/src/cppcheck-2.19.0/test/testcondition.cpp:2638(TestCondition::oppositeInnerConditionEmpty):...
-
F. Cenedese posted a comment on discussion General Discussion
On 22 Dec 2025 10:23, Tobias Markus wrote: Hello, ever since SuperTux switched over to using cppcheck 2.19, we're getting a bunch of unknown macro errors for SDL_VERSION_ATLEAST in our code. An example being: |src/control/ game_controller_manager.cpp:312:2:error:failedtoevaluate#ifcondition,undefinedfunction-likemacroinvocation:SDL_VERSION_ATLEAST(...)[syntaxError] #ifSDL_VERSION_ATLEAST(2,0,9) | Now, we're trying to suppress them. Unfortunately, the syntaxError category is a little too broad, so...
-
Jam Bon posted a comment on discussion General Discussion
Hard to say on the results, I compared some metrics from both runs: Source tree: File size: 123MB ~25min Total errors: 219938 cstyleCast: 135350 knownConditionTrueFalse: 3159 nullPointerOutOfMemory: 8344 Compilation database: File size: 23MB ~3h Total errors: 37862 cstyleCast: 15363 knownConditionTrueFalse: 349 nullPointerOutOfMemory: 5796 For the same file, the source tree based run is reporting errors but nothing in the compilation database based one (and the file is in the database of course)....
-
Tobias Markus posted a comment on discussion General Discussion
Hello, ever since SuperTux switched over to using cppcheck 2.19, we're getting a bunch of unknown macro errors for SDL_VERSION_ATLEAST in our code. An example being: src/control/game_controller_manager.cpp:312:2: error: failed to evaluate #if condition, undefined function-like macro invocation: SDL_VERSION_ATLEAST( ... ) [syntaxError] #if SDL_VERSION_ATLEAST(2, 0, 9) Now, we're trying to suppress them. Unfortunately, the syntaxError category is a little too broad, so I feel uncomfortable just adding...
-
Daniel Marjamäki created a blog post
Cppcheck-2.19.0
-
cppcheck released /cppcheck/2.19/README.md
-
-
-
-
-
-
-
-
-
-
-
I am releasing cppcheck-2.19.0 if there will be some more fixes that should be released we can release 2.19.1
-
cppcheck.xml: 123MB It's not obvious that this is better. Are the results good?
-
It's quite usual that the compilation database will be slower, as all the include paths are provided all the headers will be included in the analysis. Sometimes it's better to provide the paths and sometimes it's better to provide compilation database (if missing macros cause problems for instance). I don't know what is better for you but I like that you try out both approaches..
-
It's quite usual that the compilation database will be slower, as all the include paths are provided all the headers will be included in the analysis. Sometimes it's better to provide the paths and sometimes it's better to provide compilation database (if missing macros cause problems for instance).
-
I am trying to find the best way to analyze my project with cppcheck. $ cppcheck --version Cppcheck 2.17.1 I was benchmarking the same cppcheck command targeting: - the root of the project source tree (.) - a compilation database generated from the project source tree (--project=compile_commands.json) with otherwise the same command line: cppcheck \ --cppcheck-build-dir=cppcheck-cache \ -j 24 \ --xml \ --xml-version=2 \ --output-file=cppcheck.xml \ --enable=all \ --force \ --check-level=exhaustive...
-
I am trying to find the best way to analyze my project with cppcheck. I was benchmarking the same cppcheck command targeting: - the root of the project source tree (.) - a compilation database generated from the project source tree (--project=compile_commands.json) with otherwise the same command line: cppcheck \ --cppcheck-build-dir=cppcheck-cache \ -j 24 \ --xml \ --xml-version=2 \ --output-file=cppcheck.xml \ --enable=all \ --force \ --check-level=exhaustive --checkers-report=cppcheck.checkers-report.txt...
-
I would prefer it not be reverted but if it has to be reverted, I would like all other cmake changes put on pause until it gets merged in with a priority that it will be merged in the next release as I dont want to have to maintain a fork of cppcheck. that sounds reasonable to me.
-
Paul Fultz posted a comment on discussion Development
In my opinion it can be reverted there was suggestion about reimplementing the goodies in smaller PRs. It cannot be done in smaller PRs, and a new PR will probably be larger in order to address the other issues. I do have follow-up PRs to address the other issues but I am blocked right now as cppcheck wont build and I have PR to fix it which hasn't been merged: https://github.com/danmar/cppcheck/pull/8015(I think this is a must for any release) I would prefer it not be reverted but if it has to be...
-
No idea where we are at in terms of the CMake stuff. I don't actually understand the details of the changes nor your objections. But I think your objections was ignored too quickly when you were not able to participate. There was a sense of urgency as there is a lot of flux and therefore hard to keep the PR up-to-date. In my opinion it can be reverted there was suggestion about reimplementing the goodies in smaller PRs.
-
Oliver Stöneberg posted a comment on discussion Development
It is finally ready (CI still in progress though). Here's the PRs (in order): https://github.com/danmar/simplecpp/pull/606 https://github.com/danmar/simplecpp/pull/599 https://github.com/danmar/cppcheck/pull/8000 https://github.com/danmar/cppcheck/pull/7962 No idea where we are at in terms of the CMake stuff.
-
Sorry for the late reply. Here's an updated overview. We need to add the suppressions in https://github.com/danmar/cppcheck/pull/8008 so it can be merged. Still to be done for simple 1.6.4: https://github.com/danmar/simplecpp/pull/599 (basically ready - still want to get it a closer look tomorrow) regarding https://github.com/danmar/simplecpp/issues/556 / https://github.com/danmar/simplecpp/pull/475 I think it will be fine to release it without having the MinGW CI in-place and the known issues fixed....
-
Integrating simplecpp 1.6.4 (yet to be tagged) would fix the crash from https://trac.cppcheck.net/ticket/14268
-
I would like to release soon. Customers are waiting for some of the bug fixes. What more do you feel we need to fix before the release? Imho getting latest simplecpp fixes into cppcheck should be pretty high prio. I can help out and I can ask ludvig, oleksandr and swasti to work on some tasks if there are suggestions..
-
I would like to release soon. Customers are waiting for some of the bug fixes. What more do you feel we need to fix before the release? Imho getting latest simplecpp fixes into cppcheck should be pretty high prio. I can help out and I can ask ludvig, oleksandr and swasti to work on some tasks if there are suggestions..
-
Thanks for reporting, ticket is here: https://trac.cppcheck.net/ticket/14315
-
That seems to be a true positive. The multiplication is done using 32 bits, and the result is assigned to a 64 bit value. In case of a = 5, cppcheck knows that no overflow can occur.
-
Marcin Pytel posted a comment on discussion General Discussion
I'm using cppcheck 2.18.0 Here is code: static const int i = 0; int main() { assert(i == 0); } When running cppcheck --enable=style I have issue: cppcheckbug_4:4:10: style: The comparison 'i == 0' is always true. [knownConditionTrueFalse] assert(i == 0); ^ cppcheckbug_4:1:22: note: 'i' is assigned value '0' here. static const int i = 0; ^ cppcheckbug_4:4:10: note: The comparison 'i == 0' is always true. assert(i == 0); Although the cppcheck has right, the assert is to make sure the variable is 0...
-
I'm using cppcheck 2.18.0 Here is code: // scanf and printf are just to get rid of unused and uninitialized variable int main() { uint32_t a; scanf("%u", &a); uint32_t i = a, j = a; uint64_t k = i * j; printf("%lu", k); } When running cppcheck --enable=style I have error: style: int result is assigned to long variable. If the variable is long to avoid loss of information, then you have loss of information. [truncLongCastAssignment] uint64_t k = i * j; There's no issue when I remove the scanf and...
-
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...
-
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
-
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...
-
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.
1 >
