| commit | 35feb52e04b021a7b94fc491e38d4452cedc2fc6 | |
| author | Dan Carpenter <dan.carpenter@oracle.com> | |
| Mon, 18 Feb 2013 07:42:06 +0000 (18 10:42 +0300) | ||
| committer | Dan Carpenter <dan.carpenter@oracle.com> | |
| Mon, 18 Feb 2013 07:42:06 +0000 (18 10:42 +0300) | ||
| tree | 1d35471eef910e2f76dce4cdf6305b61c7750ddf | treesnapshot (tar.gz zip) |
| parent | a1950fd9dfd8ee61dfe41c0dab95adf0c5fee938 | commitdiff |
ranges: fix "trouble parsing empty" messages
In olden times "empty" states represented an impossible condition so they
maybe meant something had gone wrong. But these days, if they come from
param_filter then they can mean that a variable is cleared on the return
path. Which is totally valid.
We should just parse them and don't complain.
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
In olden times "empty" states represented an impossible condition so they
maybe meant something had gone wrong. But these days, if they come from
param_filter then they can mean that a variable is cleared on the return
path. Which is totally valid.
We should just parse them and don't complain.
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
| smatch_ranges.c | diffblobblamehistory |