[PATCH] [analyzer] Path-sensitive different.IntegerOverflow checker
Julia Trofimovich
t.iuliia at samsung.com
Tue Jan 20 09:28:54 PST 2015
Hello Anna,
thank you for your reply.
Could you please point a problem in this code sample? I cannot find a sample that doesn't follow this recommendation.
In this checker, we have 2 cases for throwing a report:
1. We could both overflow and not overflow (StateOverflow && StateNotOverflow). So I check if one of operands is tainted, produce a warning if so and return. It is not a source of false positives.
2. Then I check if only overflow is possible: StateOverflow && !StateNotOverflow == StateOverflow here, because StateOverflow && StateNotOverflow option was considered before.
I'll try to explain my assumptions why having 'StateOverflow && !StateNotOverflow' is not enough to get a reliable reason to warn.
The first 'if' clause is not a problem because we could definitely know if an operand is tainted so we point that we *can* overflow here. The main source of false positives are values that are reasoned to overflow by analyzer but cannot overflow due to possible checks in the caller. These values are values of function arguments and global variables, for example. I collect these values in 'ExternalSym' set. This is what I am filtering out. In this case analyzer's constraints are not enough to suggest an overflow so we make an additional check.
http://reviews.llvm.org/D4066
EMAIL PREFERENCES
http://reviews.llvm.org/settings/panel/emailpreferences/
More information about the cfe-commits
mailing list