-
Notifications
You must be signed in to change notification settings - Fork 1.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
C++: Fix FPs in cpp/unsigned-difference-expression-compared-zero
#16988
C++: Fix FPs in cpp/unsigned-difference-expression-compared-zero
#16988
Conversation
* These serve as the base cases for `exprIsSubLeftOrLess`. | ||
*/ | ||
Expr exprIsLeftOrLessBase(SubExpr sub) { | ||
interestingSubExpr(sub, _) and // Manual magic |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Note: There's a subtle change here in the structure of how the exprIsSubLeftOrLess
predicate is evaluated. On main
we join with interestingSubExpr(sub, _)
in every iteration of the recursion. However, by moving this conjunct into exprIsLeftOrLessBase
we're only joining with interestingSubExpr(sub, _)
in the base case only. This is really what we want since sub
doesn't change throughout the recursion, so we only need the interestingSubExpr(sub, _)
conjunct to restrict the base case. Joining with this in any of the recursive cases is wasted work ... Of course this totally doesn't matter since the predicate is so small anyway (because of the interestingSubExpr(sub, _)
conjunct).
DCA looks good: The two FPs that are removed were the two I was expecting to see 🎉 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM.
I had to remind myself that the query is looking for cases where the result can never be negative, not just cases where the result is always positive. i.e. the query is looking for "probably not what the programmer intended" not "definitely redundant comparison".
Ideally, this should just be done by using the shared range analysis library. However, in a follow-up PR I'm suggesting that we move this query into Code Scanning, and we're not quite ready to pull that library into Code Scanning just yet.
So for now I've added the most common/easy cases here. In fact, only the
BitwiseAndExpr
case had an impact on MRVA, and the rest are just for more thorough coverage.Commit-by-commit review recommended