It's time to start discussing release of Cppcheck-2.2
From now on I would like that we all have some focus on fixing bugs/crashes/hangs/etc.. Small "safe" improvements are ok. Bigger improvements is probably better to put in a branch for a while.
I am hoping we can release Cppcheck in 2-4 weeks.
What are the blockers? Feel free to point out bugs you think are extra serious.
It seems that Cppcheck got ~30% slower. According to the time report: http://cppcheck1.osuosl.org:8000/time.html
I do not think that is a blocker but well it's something to wonder about.
I wish we can reduce number of "open defects".
Last edit: Daniel Marjamäki 2020-09-10
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
For information when I look at daca@home warnings now, I do not think that it looks very good. Our noise ratio is higher than it used to be. As far as I remember most warnings where true positives a few years ago.
An explanation could be that Cppcheck has been actively used and projects fix the true positives. Now the false positives remain.. that would be positive for us, it's easier to find false positives.
Last edit: Daniel Marjamäki 2020-09-27
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
For information when I look at daca@home warnings now, I do not think that it looks very good. Our noise ratio is higher than it used to be. As far as I remember most warnings where true positives a few years ago.
In this release we have fixed a lot of FPs from previous releases. Checks like nullPointerRedundantCheck or zerodivcond have even decreased in number.
A lot of warnings seem to be inconclusive, but we dont print whether its inconclusive or not, so its hard to tell. It also would be nice if it could print the backtrace as it can provide better insights into our analysis.
Also, as we add new checks or enhance the current ones, it exposes latent bugs in other components. For example, this issue with knownEmptyContainer:
The bug was in isVariableChangedByFunctionCall which most likely affected other analysis as well, but it wasn't known until we added the knownEmptyContainer check.
Finally, I run this regular on the different codebases we have at work, I haven't really seen a major increase in FPs. The only major FP, I have seen is from these issues:
It's time to start discussing release of Cppcheck-2.2
From now on I would like that we all have some focus on fixing bugs/crashes/hangs/etc.. Small "safe" improvements are ok. Bigger improvements is probably better to put in a branch for a while.
I am hoping we can release Cppcheck in 2-4 weeks.
What are the blockers? Feel free to point out bugs you think are extra serious.
There are too many crashes right now: http://cppcheck1.osuosl.org:8000/crash.html
It seems that Cppcheck got ~30% slower. According to the time report: http://cppcheck1.osuosl.org:8000/time.html
I do not think that is a blocker but well it's something to wonder about.
I wish we can reduce number of "open defects".
Last edit: Daniel Marjamäki 2020-09-10
It's far from perfect. But it never is. I suggest that we release Cppcheck-2.2 next weekend, on october 3rd.
For information when I look at
daca@homewarnings now, I do not think that it looks very good. Our noise ratio is higher than it used to be. As far as I remember most warnings where true positives a few years ago.An explanation could be that Cppcheck has been actively used and projects fix the true positives. Now the false positives remain.. that would be positive for us, it's easier to find false positives.
Last edit: Daniel Marjamäki 2020-09-27
In this release we have fixed a lot of FPs from previous releases. Checks like
nullPointerRedundantCheckorzerodivcondhave even decreased in number.A lot of warnings seem to be inconclusive, but we dont print whether its inconclusive or not, so its hard to tell. It also would be nice if it could print the backtrace as it can provide better insights into our analysis.
Also, as we add new checks or enhance the current ones, it exposes latent bugs in other components. For example, this issue with
knownEmptyContainer:https://trac.cppcheck.net/ticket/9869
The bug was in
isVariableChangedByFunctionCallwhich most likely affected other analysis as well, but it wasn't known until we added theknownEmptyContainercheck.Finally, I run this regular on the different codebases we have at work, I haven't really seen a major increase in FPs. The only major FP, I have seen is from these issues:
https://trac.cppcheck.net/ticket/9666
https://trac.cppcheck.net/ticket/8909
Which borderlines on undefined behaviour.
Maybe others have had different experiences.
Actually we do that now since d615dba6384cebc06d742ebe7b0bb584381dda67
I also run it on a few different code bases at work (C++) and the noise ratio is acceptable in those code bases.