parse_call_math: work around for loops
commite59921de03e0aa0122619571317848cfd713f1b5
authorDan Carpenter <dan.carpenter@oracle.com>
Wed, 15 Mar 2017 11:54:14 +0000 (15 14:54 +0300)
committerDan Carpenter <dan.carpenter@oracle.com>
Wed, 15 Mar 2017 11:54:14 +0000 (15 14:54 +0300)
tree856acc251db6360ae8631212c5a45c0f8b50a4ae
parent79c5f8c9b224e46e2a97db9fbf837dc1911ea8cf
parse_call_math: work around for loops

The problem here starts with the fact that Smatch handles loops in a hacky
way.  Say we have a loop:

for (n = 0; n < some_variable; n++) {
if (frob())
return n;
}

Because of how Smatch handles loops it's implied that "n" is "0-s32max - 1"
but "n" hasn't been modified since we set "n = 0" because we only parse the
loop one time.  So when we're trying to tie "n" to a parameter we see that
actually "n" here always comes from the "n = 0" assignment.

So in terms of "math" then "n" is zero.  So the return value is
"0-2147483646[0]" where 0-2147483646 comes from smatch_extra.c and [0]
comes from parameter math.

But really we don't want to be returning literals as param math ever.  We
only want it in terms of parameters.  So it's fair enough to just add this
hack around and avoid fixing loops for now...

Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
smatch_parse_call_math.c