function_hooks: function comparisons can imply a parameter value
commit87f76c6390753ac8577457c0c169ebde61fd1285
authorDan Carpenter <dan.carpenter@oracle.com>
Wed, 8 Oct 2014 12:17:06 +0000 (8 15:17 +0300)
committerDan Carpenter <dan.carpenter@oracle.com>
Wed, 8 Oct 2014 12:17:06 +0000 (8 15:17 +0300)
tree3b4f10c6a75807bd174405a8d8430f1900641fab
parent9bc9d7169964f35ae863c3ce79e0a93bc7b6f410
function_hooks: function comparisons can imply a parameter value

Say we have a function like:
int frob(int x)
{
;;;;;;;;;
return x;
}

And we call it like this:

if (frob(x) < 5)
__smatch_implied(x);

It should say that the implication is that x = s32min-4.

To make that work I had to make some changes to smatch_function_hooks.c.
The main thing is that before we would take a return and say is this return
possibly true?  If so then put it in the true bucket.  Now we say if this
return is true the take the specific values which are true by calling
filter_by_comparison() on the ret_range and put those in the true bucket.

In other words, originally we would say "s32min-s32max" can be true so
that's the ret_range.  Now we say "s32min-4" is the ret_range.

The next thing is that we treat return ranges like "s32min-s32max[==$0]"
as a special case and update SMATCH_EXTRA when we see those.  That's the
handle_ret_equals_param() function.

The third change which is a cleanup is that I handle "db_info->left" with
the flip_comparison() function.  The ret_range has to be on the left side
of the comparison for the filter_by_comparison() function to work.  Also
the possibly_true/false_rl_LR() functions are ugly so now we don't have to
use them.

The other thing is that in the original code we used to just store the
ret_range as "[==$0]" but it's better to return the range_list as well like
"s32min-s32max[==$0]".  I'm not positive that these are always whole
ranges.

Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
smatch.h
smatch_db.c
smatch_function_hooks.c
smatch_ranges.c