Fix #8192: FN condition always false in for loop condition#8446
Fix #8192: FN condition always false in for loop condition#8446francois-berder wants to merge 1 commit intocppcheck-opensource:mainfrom
Conversation
|
|
tweaking the valueflow can have effects in various checkers.. I think it would be interesting if you run cppcheck/tools/test-my-pr.py script on 1000 or so packages and see what the changes are. Will you see more warnings, fewer warnings, which warnings.. A command like |
Unfortunately, I am having trouble testing my PR in this way. While running I also tried in a different way by downloading the DACA2 packages using |
I can reproduce that.. will fix it.. |
|
When #8491 has been merged, I suggest you update your main branch and rebase this PR.. and then you should be able to test it out properly. When I tested your changes I got some crashes: I don't know for sure if these crashes was caused by your changes. But I have the feeling that main branch without your changes didn't crash, and my local branch with your changes did crash. |
|
I rebased on top of 950567e and I ran |
francois-berder
force-pushed
the
pr-8192
branch
from
5bb3ca7 to
2209cc3
Compare
|
The idea is that you will look at the warnings also and decide if they are correct. If there had been 100's of warnings you could have looked at a random subset but I only see 2 warnings in your my_check_diff.log: https://ftp.debian.org/debian/pool/main/p/psautohint/psautohint_2.4.0.orig.tar.gz https://ftp.debian.org/debian/pool/main/v/vala-panel/vala-panel_24.05.orig.tar.bz2 |
|
For information you should be able to look at such warnings with this tool: cppcheck/tools/triage |
|
About this: https://ftp.debian.org/debian/pool/main/p/psautohint/psautohint_2.4.0.orig.tar.gz The code is: I don't immediately see if it's correct |
|
About this: https://ftp.debian.org/debian/pool/main/v/vala-panel/vala-panel_24.05.orig.tar.bz2 The code is: Is this a false positive? EDIT: spontanously it seems to me that "assigned value is symbolic=new_pixmap_width" is where ValueFlow made a mistake. My guess is that it should not claim that the assigned value is that. |
…ondition When a for loop's condition is impossible given the initial value (e.g. `for (int i = 0; i > 10; i++)`), cppcheck was not emitting a knownConditionTrueFalse warning. Fix by populating memory1, memory2 and memoryAfter with the init state when the condition is immediately false (and no error occured). We can then set the value for the condition token and thus emit a knownConditionTrueFalse warning. Signed-off-by: Francois Berder <fberder@outlook.fr>
francois-berder
force-pushed
the
pr-8192
branch
from
2209cc3 to
b00e38c
Compare
|
I fixed my PR (some bits were left out after rebasing on top of main). First of all, I was a little bit surprised that both logs were so different. The last log reports a lot more warnings compared to the first one. But, it does not seem like the warnings seem to be related to be caused by this PR. Finally, no crashes reported in both logs. I am going to have a look at cppcheck/tools/triage. |
If I am not mistaken the "main" branch it compares against is the upstream main branch. So make sure your main branch is synced with upstream before you execute test-my-pr.py. I agree that all those uninitMember.. are unrelated to your changes. I think 256 packages is not so much and well if it would be practical for you to run on 1000 or more packages that would give me more confidence. |
2 participants
When a for loop's condition is impossible given the initial value (e.g.
for (int i = 0; i > 10; i++)), cppcheck was not emitting a knownConditionTrueFalse warning.Fix by populating memory1, memory2 and memoryAfter with the init state when the condition is immediately false (and no error occured). We can then set the value for the condition token and thus emit a knownConditionTrueFalse warning.