Fix #11389 Do not warn for truncLongCastReturn if operands have known valid int#8192
Merged
danmar merged 4 commits intodanmar:mainfrom Feb 24, 2026
Merged
Conversation
danmar
reviewed
Feb 9, 2026
Owner
danmar
left a comment
danmar
left a comment
There was a problem hiding this comment.
thanks! I would like some test cases. One case where we don't write a false positive.
And verify that we still warn when we want.
ceJce
force-pushed
the
fix11389_unnecessary_truncLongCastReturn
branch
2 times, most recently
from
968f597 to
2c262a0
Compare
Contributor
Author
Tests added. |
ceJce
force-pushed
the
fix11389_unnecessary_truncLongCastReturn
branch
2 times, most recently
from
cf1e453 to
88ba04e
Compare
danmar
reviewed
Feb 20, 2026
ceJce
force-pushed
the
fix11389_unnecessary_truncLongCastReturn
branch
from
88ba04e to
452304d
Compare
ceJce
force-pushed
the
fix11389_unnecessary_truncLongCastReturn
branch
from
452304d to
976db09
Compare
|
francois-berder
added a commit
to francois-berder/cppcheck
that referenced
this pull request
Apr 13, 2026
… condition 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. The root cause was in valueFlowForLoop2: when the condition evaluated to false on the first check (against the init state), the function returned false immediately without populating any output maps, so the caller had no information to work with. Fix by populating memory1 and memoryAfter with the init-state when the condition is immediately false (and !error), and returning true. The caller detects this NeverRuns case via memory1 == memoryAfter (they share the same ProgramMemory map pointer due to copy-on-write semantics), then sets a known(0) value on the condition token. Signed-off-by: Francois Berder <fberder@outlook.fr>
francois-berder
added a commit
to francois-berder/cppcheck
that referenced
this pull request
Apr 13, 2026
… condition 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. The root cause was in valueFlowForLoop2: when the condition evaluated to false on the first check (against the init state), the function returned false immediately without populating any output maps, so the caller had no information to work with. Fix by populating memory1 and memoryAfter with the init-state when the condition is immediately false (and !error), and returning true. The caller detects this NeverRuns case via memory1 == memoryAfter (they share the same ProgramMemory map pointer due to copy-on-write semantics), then sets a known(0) value on the condition token. Signed-off-by: Francois Berder <fberder@outlook.fr>
francois-berder
added a commit
to francois-berder/cppcheck
that referenced
this pull request
Apr 13, 2026
… condition 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. Signed-off-by: Francois Berder <fberder@outlook.fr>
francois-berder
added a commit
to francois-berder/cppcheck
that referenced
this pull request
Apr 13, 2026
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
added a commit
to francois-berder/cppcheck
that referenced
this pull request
Apr 13, 2026
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>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This fix handles the first example in ticket, i.e. when the value is known to be a valid int:
long f() {
int n = 1;
return n << 12;
}