| commit | 68b5ad7082f1c5da651f844cd3973d4522d86bbb | |
| author | Dan Carpenter <error27@gmail.com> | |
| Mon, 4 May 2009 15:31:59 +0000 (4 18:31 +0300) | ||
| committer | Dan Carpenter <error27@gmail.com> | |
| Mon, 4 May 2009 15:31:59 +0000 (4 18:31 +0300) | ||
| tree | 312201bef277bd2665b1b373044c35d1e76f5b09 | treesnapshot (tar.gz zip) |
| parent | cfc0aa60f5bb47de1d26ee7bef5adc1d98c6e4ee | commitdiff |
potential bug fix for gotos with implications
I can't think how to write a test case for this, but I think it is a bug
fix.
With gotos and switch statements we have to call clone_slist_and_states().
But say we clone a merged state, then decide that the unmerged state is
implied. It's the same as if we didn't clone the states. It probably
causes the roughly the same bugs.
Anyway, I can't see a downside to cloning the state here except that it
uses more memory.
we already do this for implications inside switch statements so that
doesn't need to be modified.
Signed-off-by: Dan Carpenter <error27@gmail.com>
I can't think how to write a test case for this, but I think it is a bug
fix.
With gotos and switch statements we have to call clone_slist_and_states().
But say we clone a merged state, then decide that the unmerged state is
implied. It's the same as if we didn't clone the states. It probably
causes the roughly the same bugs.
Anyway, I can't see a downside to cloning the state here except that it
uses more memory.
we already do this for implications inside switch statements so that
doesn't need to be modified.
Signed-off-by: Dan Carpenter <error27@gmail.com>
| smatch_implied.c | diffblobblamehistory |