This is a very hacky fix for the restrict keyword that is presented just to start a discussion. It only deletes the restrict keyword if it is used properly.
diff --git a/lib/tokenize.cpp b/lib/tokenize.cppindex 20e30ff3d..b98f18b84 100644--- a/lib/tokenize.cpp+++ b/lib/tokenize.cpp@@ -10105,8 +10105,10 @@ void Tokenizer::simplifyKeyword()
tok->deleteNext();
if (c99) {
- while (tok->str() == "restrict")- tok->deleteThis();+ if (tok->str() == "restrict") {+ if ((tok->strAt(-1) == "*" && !tok->next()->isName()) || tok->strAt(-1) == "[" || tok->strAt(1) == "*")+ tok->deleteThis();+ }
if (mSettings->standards.c >= Standards::C11) {
while (tok->str() == "_Atomic")
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
A syntax error is good if we really want to have some user action. But I think, in this case it's fine to just keep "restrict" and continue analysis. Feel free to create a PR.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I have reduced the crashing code of the package "pcl" and created a ticket: https://trac.cppcheck.net/ticket/9492
"libmemcached" and "wiggle" seem to crash at the same point in Cppcheck.
The stack traces for the crashes in "gdb", "gcc-avr", "nyquist", "openjdk-8-jre-dcevm", "sparse" and "libnewlib-nano" look very similar. I wonder if fixing the above ticket solves all these crashes.
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?
Last edit: versat 2019-12-03
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
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
While debugging Cppcheck I can see that getLifetimeTokens() is also called recursively several (at least 20) times.
Maybe there should be some time limit or depth limit until getLifetimeTokens() gives up?
Last edit: versat 2019-12-10
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Maybe it could probably be lowered. Even better would be to avoid cycling through direct recursion. If the function being called is the same as the current function then we should lower the depth to 1 or 2.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
It's busy for me right now at work. I will work until december 17th .. I want to fix a few bugs when I have vacation .. and after that I can hopefully release 1.90 soon. Just need to sync about a good date for the release.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
All these crashes are related with not checking if condTok is null.
astutils.cpp:1649
if (condTok->hasKnownIntValue()) {
Yes, see also https://sourceforge.net/p/cppcheck/discussion/development/thread/6eb7826095/?page=1&limit=25#5ee3
This is a very hacky fix for the restrict keyword that is presented just to start a discussion. It only deletes the restrict keyword if it is used properly.
hmm.. that is also an option.
A syntax error is good if we really want to have some user action. But I think, in this case it's fine to just keep "restrict" and continue analysis. Feel free to create a PR.
I have reduced the crashing code of the package "pcl" and created a ticket:
https://trac.cppcheck.net/ticket/9492
"libmemcached" and "wiggle" seem to crash at the same point in Cppcheck.
The stack traces for the crashes in "gdb", "gcc-avr", "nyquist", "openjdk-8-jre-dcevm", "sparse" and "libnewlib-nano" look very similar. I wonder if fixing the above ticket solves all these crashes.
Is it acceptable to change the line at astutils.cpp:1649 from
to
?
This cures the crash, but is it a proper fix or only a workaround?
Last edit: versat 2019-11-29
Yes, it cures the crash which is good but doen't address why this is returning null in these cases.
I mean is it supposed to return NULL for these cases or is it also a defect in the parser code?
Last edit: x-flow 2019-11-29
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?
Last edit: versat 2019-12-03
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 fileflightgear-3.0.0/src/Input/FGKeyboardInput.cxx. There is a function with recursive calls: FGKeyboardInput::_find_key_bindingsWhile debugging Cppcheck I can see that
getLifetimeTokens()is also called recursively several (at least 20) times.Maybe there should be some time limit or depth limit until
getLifetimeTokens()gives up?Last edit: versat 2019-12-10
There is already a depth limit of 20:
https://github.com/danmar/cppcheck/blob/master/lib/valueflow.h#L359
Maybe it could probably be lowered. Even better would be to avoid cycling through direct recursion. If the function being called is the same as the current function then we should lower the depth to 1 or 2.
Also, this PR should be merged before release:
https://github.com/danmar/cppcheck/pull/2433
It also would be nice if we could get this PR merged:
https://github.com/danmar/cppcheck/pull/2370
It's busy for me right now at work. I will work until december 17th .. I want to fix a few bugs when I have vacation .. and after that I can hopefully release 1.90 soon. Just need to sync about a good date for the release.
There is one new crash in the psi-plus package:
For information, I believe that cppcheck-1.90 will be released this weekend.
Thank you for sacrificing you weeked, so we can fix our code using this wonderful tool next week.
Great tools are worth the wait.