Activity for versat
-
versat posted a comment on discussion General Discussion
You can let Cppcheck output the errors and other messages with the corresponding id, severity (what you call category) and more info in an XML format via the command line ./cppcheck --errorlist
-
Hi, i have found code like the following in a project and get a warning by Cppcheck which i do not know is correct. The code is like this simplified version: #include <utility> class Base { public: int m_Base = 0; Base() = default; virtual ~Base() = default; }; class Derived : public Base { public: int m_Foo = 0; Derived() : Base() {}; Derived& operator=(Derived&& src) { if (&src != this) { Base::operator=(std::move(src)); m_Foo = src.m_Foo; } return *this; } }; For the line 21 where it says m_Foo...
-
Here is another very interesting article about issues with mmap(): https://www.golem.de/news/mmap-codeanalyse-mit-sechs-zeilen-bash-2006-148878.html It is also in german but it should be no problem to machine translate it. They also mentioned that no compiler, even with the new analysis functionality, and also Cppcheck did not find the bug. I know that such a check is not yet possible with Cppcheck, but maybe it is useful to add it.
-
Great, thanks for the feedback.
-
The download links on http://cppcheck.net/ still lead to the binaries for version 1.90 instead of 2.0.
-
This should have been fixed with this commit: https://github.com/danmar/cppcheck/commit/e17863c216c4f411fcb5b2203e827c9a986edd0a#diff-09c3865dea9f703907ed99c5590d4688 The fixed version of cppcheck-htmlreport script will be part of the next release. I suggest to download the fixed script and verify if it works for you then: https://github.com/danmar/cppcheck/blob/master/htmlreport/cppcheck-htmlreport
-
I do not know. At least I did not stumble about any binaries yet.
-
Hmm, maybe. All the other similar messages that are caused by invalid options directly quit Cppcheck with the error message. This specific error message is an exception, the analysis still starts and only this hint is printed. Adding this as a global error to the XML file could be useful. Maybe @danielmarjamaki has an opinion about that.
-
AFAIK it is not yet released (still beta) but already helped to find a critical issue in OpenSSL: https://www.openssl.org/news/secadv/20200421.txt OpenSSL 1.1.1f still contains the issue, at least daca@home seems to not find it: http://cppcheck1.osuosl.org:8000/openssl Commit with fix: https://github.com/openssl/openssl/commit/a87f3fe01a5a894aa27ccd6a239155fd129988e4
-
AFAIK it is not yet released (still beta) but already helped to find a critical issue in OpenSSL: https://www.openssl.org/news/secadv/20200421.txt
-
Thank you for reporting this, I will create a ticket. EDIT: Created ticket: https://trac.cppcheck.net/ticket/9687 (closed as duplicate)
-
Thank you for reporting this, I will create a ticket. EDIT: Created ticket: https://trac.cppcheck.net/ticket/9687
-
Thank you for reporting this, I will create a ticket.
-
Sometimes there is too much recursion during the analysis. We try to detect such problems with daca@home. krita is checked there too (in version 4.2.9 which is the latest tag). It did not seem to cause problems with the options used there: http://cppcheck1.osuosl.org:8000/krita That does not mean that there is nothing wrong with Cppcheck. But it seems to depend on something.
-
If you only want the XML output then you have to only use the output to stderr. But I suggest to use --output-file=errors.xml instead. IMHO that is more clean than catching some output.
-
Hmm, sadly I have no idea why that does not work. Pygments 2.6.1 definitely should contain the HtmlFormatter. Have you found a solution? What Python 2.7 Version are you using exactly?
-
You have to enable it in the project settings: File -> Edit Project File -> Addons and Tools -> Clang-tidy
-
Hmm, I am not aware of such a functionality in Cppcheck itself. I am not sure if only analysing the changed files could miss any errors, so I would always run a full analysis and compare the results. What also comes to my mind is using --cppcheck-build-dir=. From the help: --cppcheck-build-dir=<dir> Analysis output directory. Useful for various data. Some possible usages are; whole program analysis, incremental analysis, distributed analysis. I am not sure if the incremental analysis that is mentioned...
-
There is also another ticket which is already fixed: https://trac.cppcheck.net/ticket/9630 I closed ticket 9486 as a duplicate one. That is why I can reproduce the issue with Cppcheck 1.90 but not with the latest development code. So with the next release (I guess 2.00) the issue is fixed.
-
Thanks for reporting the issue. It looks like there is already a ticket for such issues: https://trac.cppcheck.net/ticket/9486 I will add your code as another example for the false positive issue.
-
The addin is an extra project. I suggest to ask here: https://marketplace.visualstudio.com/items?itemName=Alexium.Cppcheckadd-in#overview
-
I have merged the PR 2510. Now the donate cpu scripts should more reliably kill timed out Cppcheck analysis even when multithreading is used. I have also set up a CentOS 7.7 system in a virtual machine and for the packages that were analysed so far it looks fine. I have disabled swap as explained before. If you encounter a package that does not time out as expected after one hour then please post the URL of that package. Some issues in Cppcheck do only happen for some specific code. I can see quite...
-
The output fatal: unrecognized argument: --no-patch likely is caused by git. It seems to be an older version of git that does not support this argument. I am not sure if this is a problem, maybe it is fine. What is strange about the first case is that gdb is started, although Cppcheck finished with -999, which means that it timed out. But it seems that it received signal 11 and that results in the donate script to assume that it crashed. We will have to look into this. The second case looks fine...
-
Hmm, no that is not normal. We added a timout of one hour for a single analysis, but we detected that it could not work if several threads are used for the analysis (via the -j option). There is a Pull Request for fixing it (https://github.com/danmar/cppcheck/pull/2510). We are not sure if it works on every platform, but maybe we should try it. How many threads are you using? How do you invoke the donate script? Which platform/operating system are you using? We could try to reproduce it on a similar...
-
Hmm, no that is not normal. We added a timout of one hour for a single analysis, but we detected that it could not work if several threads are used for the analysis (via the -j option). There is a Pull Request for fixing it. We are not sure if it works on every platform, but maybe we should try it. How many threads are you using? How do you invoke the donate script? Which platform/operating system are you using? We could try to reproduce it on a similar system then and maybe fix it.
-
I do not see any problem with it, you are correct. It is a false positive from Cppcheck, the check should get enhanced I think.
-
I do not see any problem with it, you are correct. It is a false positive from Cppcheck, the check shold get enhanced I think.
-
Thank you for the report. I created a ticket for the issue: https://trac.cppcheck.net/ticket/9648
-
When specifying a windows platform and/or using the windows library Cppcheck is aware of the _countof macro. This is from windows.cfg: <define name="_countof(_Array)" value="(sizeof(_Array) / sizeof(_Array[0]))"/> Without this library configuration the warning message disappears. I guess that Cppcheck issues the warning as soon as it sees the division with the result of the sizeof(). I assume that it is not verified that the number of elements is NOT multiplied with the result of the sizeof() again...
-
Regarding the connection timeouts I am not sure what caused them. The server is working for me. The donate script you are using is not the latest, it should be updated. But I assume that this has nothing to do with the connection issues.
-
We switched to Python 3 recently (this has several advantages). If you have not yet installed Python 3 on the machines please do so. On newer Linux distributions it should already be installed. Some distros already stopped to install Python 2 by default. Then the donation script can be simply called via ./donate-cpu.py. You can also explicitly run it with Python 3 if you like: python3 ./donate-cpu.py, but that should not be necessary. And thanks for donating to the Cppcheck project!
-
We switched to Python 3 recently (this has several advantages). If you have not yet installed Python 3 on the machines please do so. On newer Linux distributions it should already be installed. Some distros already stopped to install Python 2 by default. Then the donation script can be simply called via ./donate-cpu.py. You can also explicitly run it with Python 3 if you like: python3 ./donate-cpu.py, but that should not be necessary.
-
Yes, I will create a ticket. EDIT: I created a ticket: https://trac.cppcheck.net/ticket/9642
-
Yes, I will create a ticket.
-
@danielmarjamaki What do you think?
-
For this code: display_print_line(2U, p_line2); I get this warning: Id: bughuntingInvalidArgValue There is function call, cannot determine that 1st argument value is valid. Bad value: greater than 1 The library configuration for this function looks like this: <function name="display_print_line"> <noreturn>false</noreturn> <leak-ignore/> <arg nr="1"> <not-uninit/> <not-bool/> <valid>1,2</valid> </arg> <arg nr="2"> <not-null/> <not-uninit/> <not-bool/> <strz/> </arg> </function> So 1 and 2 are the...
-
The Cppcheck warning looks correct to me. When OpenProcess() returns a valid handle then it finished successfully and the handle has to be closed accordingly. I am not sure if the error checking in case of a successful execution of OpenProcess() does make sense here. I would only expect errors to be set when OpenProcess() failed and the the handle is set to NULL. See https://docs.microsoft.com/en-us/windows/win32/api/processthreadsapi/nf-processthreadsapi-openprocess and see this link for an example:...
-
Thanks for reporting this issue. It looks like there is already a ticket in the bug tracker: https://trac.cppcheck.net/ticket/9437 (FP: Double free on realloc check)
-
Thank you for the detailed bug report. I can reproduce the issues so I have created a ticket with your bug report: https://trac.cppcheck.net/ticket/9602
-
When clang or clang++ can not be found in the path the file with the stderr output contains something like "File/Command .. not found" (in German it contains Der Befehl "clang" ist entweder falsch geschrieben oder konnte nicht gefunden werden.. There is no hint from Cppcheck that something went completely wrong. The AST (res.second) is empty. Nothing is checked, no messages are generated, but from Cppcheck's output it looks like everything went fine.
-
When clang or clang++ can not be found in the path the file with the stderr output contains something like "File .. not found" (in German it contains Der Befehl "clang" ist entweder falsch geschrieben oder konnte nicht gefunden werden.. There is no hint from Cppcheck that something went completely wrong. The AST (res.second) is empty. Nothing is checked, no messages are generated, but from Cppcheck's output it looks like everything went fine.
-
When clang or clang++ can not be found in the path the file with the stderr contains something like "File .. not found" (in German it contains Der Befehl "clang" ist entweder falsch geschrieben oder konnte nicht gefunden werden.. There is no hint from Cppcheck that something went completely wrong. The AST (res.second) is empty. Nothing is checked, no messages are generated, but from Cppcheck's output it looks like everything went fine.
-
I am not sure if I got you. Is this window the only one for which it is hard coded? Do you know where it is hard coded? Could you create a PR or give some more details?
-
When i use a MISRA.txt file that doesn't contain anything but the rule numbers, the misra.py script runs correctly (finds the violations correct) but when it can't process the MISRA.txt it doesn't throw an error it glitches out and doesn't work properly. Hmm, what I can reproduce is this: If I remove the rule text from a rule in the rule texts file then corresponding errors are not shown any longer. IIRC this is more a feature than a bug. By only adding necessary rules to a rule texts file the rules...
-
Thanks. Indeed, there are no hints for any real issues. These bailout warnings are normally no real errors. Seems like the issue actually is either not detected or at least not logged. That needs fixing.
-
Great. It works now for me under Cygwin 64. One thing I instantly noticed is a false positive that I get with --clang: $ ./cppcheck --clang --cppcheck-build-dir=./temp ./lib/check.cpp Checking ./lib/check.cpp... ./lib/check.cpp:66:12: error: Reference to local variable returned. [returnReference] return _instances; ^ Without --clang there is no false positive: $ ./cppcheck -f ./lib/check.cpp Checking lib/check.cpp ... Checking lib/check.cpp: CPPCHECKLIB_EXPORT;_WIN32... Checking lib/check.cpp: CPPCHECKLIB_IMPORT;_WIN32......
-
I managed to let cygwin start the GDB when a segmentation fault happens and got this output: (gdb) bt #0 0x00000001800d63c7 in _memcpy () from /usr/bin/cygwin1.dll #1 0x00000003bdf2c158 in cygstdc++-6!_ZNSs6appendERKSs () from /usr/bin/cygstdc++-6.dll #2 0x0000000100643447 in std::operator+<char, std::char_traits<char>, std::allocator<char> > (__lhs=<optimized out>, __rhs=...) at /usr/lib/gcc/x86_64-pccygwin/7.4.0/include/c++/bits/basic_string.tcc:1167 #3 0x00000001004b61fb in clangimport::AstNode::createTokens...
-
I managed to let cygwin start the GDB when a segmentation fault happens and got this output: (gdb) bt #0 0x00000001800d63c7 in _memcpy () from /usr/bin/cygwin1.dll #1 0x00000003bdf2c158 in cygstdc++-6!_ZNSs6appendERKSs () from /usr/bin/cygstdc++-6.dll #2 0x0000000100643447 in std::operator+<char, std::char_traits<char>, std::allo cator<char> > (__lhs=<optimized out>, __rhs=...) at /usr/lib/gcc/x86_64-pc-cygwin/7.4.0/include/c++/bits/basic_string.tcc:116 7 #3 0x00000001004b61fb in clangimport::AstNode::createTokens...
-
Somehow GDB is not able to show a backtrace for this segmentation fault: Checking ./lib/analyzerinfo.cpp... [New Thread 8984.0xab8] 0 [main] cppcheck 2155 cygwin_exception::open_stackdumpfile: Dumping stack trace to cppcheck.exe.stackdump [Thread 8984.0xab8 exited with code 35584] [Thread 8984.0xa88 exited with code 35584] [Thread 8984.0x2b8c exited with code 35584] [Inferior 1 (process 8984) exited with code 0105400] (gdb) bt No stack. The content of cppcheck.exe.stackdump is pretty useless. I will...
-
1.90 should be fine.
-
I have tried it with your change and now I get this for ./cppcheck --clang --cppcheck-build-dir=./temp -I./externals/tinyxml ./lib/analyzerinfo.cpp: CXXMethodDecl 0x80160dd88 parent 0x801542768 prev 0x801543198 <line:46:1, line:61:1> line:46:27 writeFilesTxt 'void (const std::string &, const std::list<std::string> &, const std::list<ImportProject::FileSettings> &)' ParmVarDecl 0x80160d728 <col:41, col:60> col:60 used buildDir 'const std::string &' ParmVarDecl 0x80160d9f0 <col:70, col:100> col:100...
-
Ok, here is the end of the dumpAst() output for the command ./cppcheck --clang --cppcheck-build-dir=./temp -I./externals/tinyxml ./lib/analyzerinfo.cpp, I hope I got everything that is necessary: FunctionDecl 0x8014afa28 <line:34:1, line:44:1> line:34:20 used getFilename 'std::string (const std::string &)' static ParmVarDecl 0x8014af960 <col:32, col:51> col:51 used fullpath 'const std::string &' CompoundStmt 0x8014b06c8 <line:35:1, line:44:1> DeclStmt 0x8014afd50 <line:36:5, col:63> VarDecl 0x8014afb78...
-
Ok, here is the end of the dumpAst() output, I hope I got everything that is necessary: FunctionDecl 0x8014afa28 <line:34:1, line:44:1> line:34:20 used getFilename 'std::string (const std::string &)' static ParmVarDecl 0x8014af960 <col:32, col:51> col:51 used fullpath 'const std::string &' CompoundStmt 0x8014b06c8 <line:35:1, line:44:1> DeclStmt 0x8014afd50 <line:36:5, col:63> VarDecl 0x8014afb78 <col:5, col:62> col:28 used pos1 'std::string::size_type':'unsigned long' cinit CXXMemberCallExpr 0x8014afcb8...
-
Ok, here is the the end of the dumpAst() output, I hope I got everything that is necessary: FunctionDecl 0x8014afa28 <line:34:1, line:44:1> line:34:20 used getFilename 'std::string (const std::string &)' static ParmVarDecl 0x8014af960 <col:32, col:51> col:51 used fullpath 'const std::string &' CompoundStmt 0x8014b06c8 <line:35:1, line:44:1> DeclStmt 0x8014afd50 <line:36:5, col:63> VarDecl 0x8014afb78 <col:5, col:62> col:28 used pos1 'std::string::size_type':'unsigned long' cinit CXXMemberCallExpr...
-
I have not looked into the clang import, just saw that you are working on it. What exactly should the clang import do? From what I saw until now my guess is that clang is used to create the AST instead of internal code like simplecpp. I thought I just test it so I maybe get a better understanding of it, but it crashed. Not sure what went wrong (I used Cygwin 64 on Windows 7): $ ./cppcheck --clang --cppcheck-build-dir=./temp -I./externals/tinyxml ./lib/analyzerinfo.cpp Checking ./lib/analyzerinfo.cpp......
-
I have not looked into the clang import, just saw that you are working on it. What exactly should the clang import do? From what I saw until now my guess is that clang is used to create the AST instead of internal code like simplecpp. I thought I just test it so I maybe get a better understanding of it, but it crashed. Not sure what went wrong (I used Cygwin 64 on Windows 7): $ ./cppcheck --clang --cppcheck-build-dir=./temp -I./externals/tinyxml ./lib/analyzerinfo.cpp Checking ./lib/analyzerinfo.cpp......
-
I have not looked into the clang import, just saw that you are working on it. What exactly should the clang import do? From what I saw until now my guess is that clang is used to create the AST instead of internal code like simplecpp. I thought I just test it so I maybe get a better understanding of it, but it crashed. Not sure what went wrong (I used Cygwin 64 on Windows 7): $ ./cppcheck --clang --cppcheck-build-dir=./temp -I./externals/tinyxml ./lib/analyzerinfo.cpp Checking ./lib/analyzerinfo.cpp......
-
I have not looked into the clang import, just saw that you are working on it. What exactly should the clang import do? From what I saw until now my guess is that clang is used to create the AST instead of internal code like simplecpp. I thought I just test it so I maybe get a better understanding of it, but it crashed. Not sure what went wrong (I used Cygwin 64 on Windows 7): $ ./cppcheck --clang --cppcheck-build-dir=./temp -I./externals/tinyxml ./lib/analyzerinfo.cpp Checking ./lib/analyzerinfo.cpp......
-
I have not looked into the clang import, just saw that you are working on it. What exactly should the clang import do? From what I saw until now my guess is that clang is used to create the AST instead of internal code like simplecpp. I thought I just test it so I maybe get a better understanding of it, but it crashed. Not sure what went wrong: $ ./cppcheck --clang --cppcheck-build-dir=./temp -I./externals/tinyxml ./lib/analyzerinfo.cpp Checking ./lib/analyzerinfo.cpp... Segmentation fault (core...
-
Just an idea: We could add a button in the GUI for testing the MISRA configuration/requirements like Python installation/binary and rule text file. @Richard Bamford: Can you check if the "Analysis Log" in the GUI gives any information about a problem with the MISRA analysis? I have added some output for cases where there is a problem with Python. I guess that for your case there is nothing logged, but who knows.
-
Have you tried a relative (to the project) path for the -i parameter? The --check-config option is only useful to verify whether all includes are found. For nomal analysis it does not have to be used because it aborts before the analysis. Since you added these options directly as command line argument I think it is ok to ask here. Otherwise the cppchecklipse plugin is a different project which can be found here: https://github.com/kwin/cppcheclipse Maybe they can help better with the problem.
-
Yes that looks wrong. The boolean variables are cast to integers and the shifted. So clearly there is no boolean any longer. Cppcheck should know that, no reason to mark it inconclusive I guess. Maybe this message is intended, I am not sure. I created a ticket for this: https://trac.cppcheck.net/ticket/9586
-
Yes that looks wrong. The boolean variables are cast to integers and the shifted. So clearly there is no boolean any longer. Cppcheck should know that, no reason to mark it inconclusive I guess.
-
I closed the ticket. You were right, I was somehow using not the latest compiled code. sizeof() does no longer issue these false positives.
-
It looks like GCC gets a static analyzer this year. As far as I understand it is only available for C code at the beginning. Some interesting links with more info: News from Phoronix: https://phoronix.com/scan.php?page=news_item&px=GCC-Static-Analysis-RH-Patches Post in the GCC mailing list about the static analysis patches: https://gcc.gnu.org/ml/gcc-patches/2019-11/msg01543.html GCC analyzer options: https://gcc.gnu.org/onlinedocs/gcc/Static-Analyzer-Options.html German article where I first read...
-
I created a ticket for (what I think is) a false positive: https://trac.cppcheck.net/ticket/9583 (False positive: Bug Hunting: verificationDivByZero for sizeof(), but can not be 0) Hmm. The error id verificationDivByZero has still verification in its name. Maybe that should be changed too?
-
Thanks. make USE_Z3=yes works now for me. And analyzing my project also works with z3 now. Maybe there is something that could be improved when not using z3. Without z3 analyzing xcrypt.c uses all memory and then prints this error: Checking ../cntlm_versat/xcrypt.c ... Verify: Aborted analysis of function 'gl_des_ecb_crypt': std::bad_alloc Checking ../cntlm_versat/xcrypt.c: _STRING_ARCH_unaligned=0... If you want to have a look at the function gl_des_ecb_crypt() you can view it here: https://github.com/versat/cntlm/blob/ccf44bd040bd7d653e0f53029b688214958fdc3e/xcrypt.c#L522...
-
As far as I remember this was a false positive that has been fixed in one of the last released versions. When the allocation, assignment and comparision for null pointer was in the same if clause then Cppcheck produced false positives. I would try using a newer Cppcheck version. Cppcheck 1.90 has been released a few weeks ago. There were many things fixed and enhancements added since 1.82.
-
Ok. I have installed libz3-4 and libz3-dev under Debian 10.1 and tried to compile Cppcheck HEAD with USE_Z3=yes. I get this error: g++ -Ilib -isystem externals -isystem externals/simplecpp -isystem externals/tinyxml -DUSE_Z3 -pedantic -Wall -Wextra -Wcast-qual -Wno-deprecated-declarations -Wfloat-equal -Wmissing-declarations -Wmissing-format-attribute -Wno-long-long -Wpacked -Wredundant-decls -Wundef -Wno-shadow -Wno-missing-field-initializers -Wno-missing-braces -Wno-sign-compare -Wno-multichar...
-
I did not link with z3. I knew that it can be used but do not know much about it. Would you expect a drastic performance improvement with the z3 library? I guess this is the correct repository: https://github.com/Z3Prover/z3 The libz3.dll for x64 is about 14 MB in size. We would need the libz3.dll for x86 too I guess. IMHO this is a bit too much for committing it to the Cppcheck repository. The includes are "only" some hundred KB, that would be acceptable I guess. Hmm, not sure if it makes sense...
-
I tested --bug-hunting on a project I am working on. When analyzing the file xcrypt.c Cppcheck uses all RAM when --bug-hunting is enabled. To reproduce this it is enough to download xcrypt.c and xcrypt.h and run ./cppcheck --bug-hunting xcrypt.c. On my PC after nearly a minute all the RAM is used. Tested on Windows 7, compiled with Visual Studio 2019.
-
Do you think it is useful to add --bug-hunting to the daca@home client? There are only extra checks if I understand it correctly, so I guess it should be OK.
-
New Kickstarter Project (Add all missing MISRA C 2012 rules for essential types): https://sourceforge.net/p/cppcheck/discussion/general/thread/a4baadcf2f/
-
Yes it is in qt.cfg: <define name="Q_DECLARE_METATYPE(x)" value=""/> Does the macro usage in the code has exactly one argument? Is the Qt library configuration explicitly used for example by adding the command line option --library=qt?
-
There is one new crash in the psi-plus package: Checking temp/psi-plus-snapshots-1.4.976/iris/src/xmpp/xmpp-im/jingle-s5b.cpp: __GNUC__=1... Thread 1 "cppcheck" received signal SIGSEGV, Segmentation fault. valueFlowReverse (tokenlist=tokenlist@entry=0xffffb3e0, tok=tok@entry=0x60153cb60, varToken=varToken@entry=0x60153cdc0, val=..., val2=..., errorLogger=errorLogger@entry=0xffffbbf0, settings=settings@entry=0xffffbde8) at build/valueflow.cpp:3520 3520 if (!assignTok->hasKnownValue()) { #0 valueFlowReverse...
-
Can you create a Pull Request at https://github.com/danmar/cppcheck ?
-
Just to get it right: You wrote in the issue report that you used 1.88, but in fact 1.84 has been used? And with 1.88 it is no longer detected? Can you try to create a reduced example with 1.84 where the issue is detected? I can imagine that in the line NEWCHECK(buf = new unsigned char[len]); the macro NEWCHECK() is not known to Cppcheck and that has something to do with the false negative.
-
The crashes are fixed now and in my opinion the quality is way better now. One thing I have detected that is not so great is that the analysis of the "flightgear" package is about 1400 times slower than before (see also http://cppcheck1.osuosl.org:8000/time.html). I have tried it locally and I can see that Cppcheck is extremely long in the function valueflow.cpp:getLifetimeTokens() when analysing the file flightgear-3.0.0/src/Input/FGKeyboardInput.cxx. There is a function with recursive calls: FGKeyboardInput::_find_key_bindings...
-
The crashes are fixed now and in my opinion the quality is way better now. One thing I have detected that is not so great is that the analysis of the "flightgear" package is about 1400 times slower than before (see also http://cppcheck1.osuosl.org:8000/time.html). I have tried it locally and I can see that Cppcheck is extremely long in the function valueflow.cpp:getLifetimeTokens() when analysing the file flightgear-3.0.0/src/Input/FGKeyboardInput.cxx. There is a function with recursive calls: FGKeyboardInput::_find_key_bindings...
-
The crashes are fixed now and in my opinion the quality is way better now. One thing I have detected that is not so great is that the analysis of the "flightgear" package is about 1400 times slower than before. I have tried it locally and I can see that Cppcheck is extremely long in the function valueflow.cpp:getLifetimeTokens() when analysing the file flightgear-3.0.0/src/Input/FGKeyboardInput.cxx. There is a function with recursive calls: FGKeyboardInput::_find_key_bindings While debugging Cppcheck...
-
I have created a ticket: https://trac.cppcheck.net/ticket/9527
-
While trying to reproduce the issue and finding a minimal example I found out something. When the if condition is changed to testEnum_a & testEnum_b & e the issue is reported: $ ./cppcheck --enable=style forum.c Checking forum.c ... forum.c:11:33: style: Condition 'testEnum_a&testEnum_b&e' is always false [knownConditionTrueFalse] if( testEnum_a & testEnum_b & e) ^ So it matters where exactly the unknown/unsure variable value is in the condition. But in this case that does not make a difference and...
-
While trying to reproduce the issue and finding a minimal example I found out something. When the if condition is changed to testEnum_a & testEnum_b & e the issue is reported: $ ./cppcheck --enable=style forum.c Checking forum.c ... forum.c:11:33: style: Condition 'testEnum_a&testEnum_b&e' is always false [knownConditionTrueFalse] if( testEnum_a & testEnum_b & e) ^ So it matters where exactly the unknown/unsure variable value is in the condition. But in this case that does not make a difference and...
-
You are right, testEnum_a & testEnum_b will always be false, so Cppcheck could warn even if the value of e is not known. Maybe some check to avoid false positives avoids this warning to be generated, but I do not know. I think this false negative is worth a ticket.
-
You are right, testEnum_a & testEnum_b will always be false, so Cppcheck could warn even if the value of e is not known. Maybe some check to avoid false positives avoids this warning to be generated, but I do not know. I think this is worth a ticket reporting this false negative.
-
I have reproduced it (thanks for the detailed report, it was no problem) and I found something. The interesting place is here: https://github.com/danmar/cppcheck/blob/0507b1a2b62eb095871606adfcafa9c210aaa971/lib/errorlogger.cpp#L565 Debugging through this loop shows that this should work (note the :* after unmatchedSuppression): cppcheck --enable=all --suppress=*:include/* --suppress=unmatchedSuppression:* IncludeNothing.cpp while this does not work (as you wrote): cppcheck --enable=all --suppress=*:include/*...
-
I have reproduced it (thanks for the detailed report, it was no problem) and I found something. The interesting place is here: https://github.com/danmar/cppcheck/blob/0507b1a2b62eb095871606adfcafa9c210aaa971/lib/errorlogger.cpp#L565 Debugging through this loop shows that this should work (note the :* after unmatchedSuppression): cppcheck --enable=all --suppress=*:include/* --suppress=unmatchedSuppression:* IncludeNothing.cpp while this does not work (as you wrote): cppcheck --enable=all --suppress=*:include/*...
-
I have reproduced it (thanks for the detailed report, it was no problem) and I found something. The interesting place is here: https://github.com/danmar/cppcheck/blob/0507b1a2b62eb095871606adfcafa9c210aaa971/lib/errorlogger.cpp#L565 Debugging through this loop shows that this should work (note the :* after unmatchedSuppression): cppcheck --enable=all --suppress=*:include/* --suppress=unmatchedSuppression:* IncludeNothing.cpp while this does not work (as your wrote): cppcheck --enable=all --suppress=*:include/*...
-
It looks like operator overloading or so is necessary to use such a comma-separated initializer. Not sure how this is implemented. Creating a library configuration for OpenCV is on my TODO list. I have not used OpenCV, so I am not familiar with it, but I wanted to create an initial configuration that can be futher enhanced then. While this library configuration could help with some issues, I am not sure if it can help in that case. Not everything can be configured in that file. Maybe someone else...
-
In simplecpp I have not found a way to do this, in Cppcheck it is possible by simply using an empty string instead of the file name. It would look like this then: $ ./cppcheck --include=blah1.h foo.c Checking foo.c ... nofile:0:0: error: Can not open include file 'blah1.h' that is explicitly included. [preprocessorErrorDirective]
-
-j is used to analyze files in parallel. So if there is only one file to analyze it does not speed up anything as far as I know. Did you analyze a project with many files or just one or a few files? There are different implementations for Windows and Linux, but they should behave in the same way (For the user there should not be a difference). Under Cygwin there were severe issues with the Linux implementation (using fork) so we had to disable it here. If you try -j 2 under Cygwin it will directly...
-
-j is used to analyze files in parallel. So if there is only one file to analyze it does not speed up anything as far as I know. Did you analyze a project with many files or just one or a few files? There are different implementations for Windows and Linux, but they should behave in the same way (For the user there should not be a difference). Under Cygwin there were severe issues with the Linux implementation (using fork) so we had to disable it here. If you try -j 2 under Cygwin it will directly...
-
Just a short update: "simplecpp" now issues an error when an explicitly included file can not be included. I have created a PR that uses the new functionality from "simplecpp" so Cppcheck also exits with an error when "--include=" does not work. Something like this is then issued by Cppcheck for example when "blah1.h" does not exist: $ ./cppcheck --include=blah1.h foo.c -E foo.c:1:0: error: Can not open include file 'blah1.h' that is explicitly included. [preprocessorErrorDirective] int main() ^...
-
I agree, this is not very user friendly. IMHO it is an issue with simplecpp that is part of Cppcheck, so I created an issue there: https://github.com/danmar/simplecpp/issues/183
-
There is currently only one crash detected for 1.90 dev by daca@home. It is in the package gocr_0.52. I reduced the code and created a ticket: https://trac.cppcheck.net/ticket/9510 It is a division by zero error. Not sure how to fix it. Just return 0 if the denominator is 0?
-
There is currently only one crash detected for 1.90 dev by daca@home. It is in the package gocr_0.52. I reduced the code and created a ticket: https://trac.cppcheck.net/ticket/9510 It is a division by zero error. Not sure how to fix it. Just return 0 if the divider is 0?
-
Another advantage is the lzma/.xz support that Python 3.3 has out of the box. See https://trac.cppcheck.net/ticket/9508 For older versions there are backports, but they have to be installed manually and also explicitly supported by the script I guess.
-
I further debugged it and to me it looks like it is tried to set the buffer size in valueFlowDynamicBufferSize() for the malloced buffer buf. But that does not work. valueFlowDynamicBufferSize() is called and finds out the correct size and that malloc is used. Everything looks fine. It then calls valueFlowForwardVariable to assign the buffer size to the buffer variable I guess. But valueFlowForwardVariable() does not do anything with the given data as far as I see. To me it looks like such a case...
-
For the initial example the function getBufferSizeValue() called at https://github.com/danmar/cppcheck/blob/91dd8d3b6f055e5f98bc32d5e57a37a9420b966b/lib/checkbufferoverrun.cpp#L210 does return a nullptr for buf. Not sure if that could be the issue. I have no time to analyse this further now.
-
I have created a ticket: https://trac.cppcheck.net/ticket/9502 Thanks for reporting this.
1 >