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
Creating a .cfg file with the necessary defines is probably the way to go.
-
Matthew Markland posted a comment on discussion General Discussion
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...
-
Daniel Marjamäki posted a comment on discussion Development
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.
-
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...
1 >
