| commit | eb5c7abab93315686e78b2637aa2a3e7a9a95b76 | |
| author | Dan Carpenter <dan.carpenter@oracle.com> | |
| Fri, 27 Jan 2017 09:30:26 +0000 (27 12:30 +0300) | ||
| committer | Dan Carpenter <dan.carpenter@oracle.com> | |
| Fri, 27 Jan 2017 09:31:09 +0000 (27 12:31 +0300) | ||
| tree | a95f71d3b91948fb4888d50171a0ec9b2acf3db1 | treesnapshot (tar.gz zip) |
| parent | f812c4d3e93e642157b6a0cccd418505136f6f6b | commitdiff |
extra: filter PARAM_VALUEs with both extra and real_absolute
The problem is that we sometimes record a PARAM_VALUE as s32min-10 when
it should be 0-10. The example code looks something like this:
int a = unknown_u8;
if (a > 10)
return;
frob(a);
Smatch_extra looks at the initial assignment and says it doesn't tell us
anything. Real absolute looks at it and says a is 0-255. Smatch extra
see the comparison and says that is less than 11 so s32min-10. Now in
the new code, when we call frob() we combine those to say that the param
value is 0-10.
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
The problem is that we sometimes record a PARAM_VALUE as s32min-10 when
it should be 0-10. The example code looks something like this:
int a = unknown_u8;
if (a > 10)
return;
frob(a);
Smatch_extra looks at the initial assignment and says it doesn't tell us
anything. Real absolute looks at it and says a is 0-255. Smatch extra
see the comparison and says that is less than 11 so s32min-10. Now in
the new code, when we call frob() we combine those to say that the param
value is 0-10.
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
| smatch_extra.c | diffblobblamehistory |