implied: revert not already set change
commitdeeabc9e0e11f10e5520445729cdbdd5ee549f9b
authorDan Carpenter <dan.carpenter@oracle.com>
Mon, 29 Feb 2016 14:55:31 +0000 (29 17:55 +0300)
committerDan Carpenter <dan.carpenter@oracle.com>
Fri, 4 Mar 2016 19:56:05 +0000 (4 22:56 +0300)
tree4c96efd4695b25b40773fe2e2ba52bca16b7cee3
parent5b213fd7c37f3baa9c1c75f4357248bb809a8d3c
implied: revert not already set change

This stuff is complicated and there are several issues involved.

Say you have:

        if (!({
                int __ret;

                flags = arch_local_irq_save();

                __ret = spin_trylock(&lock);
                if (!__ret)
                        arch_local_irq_restore(flags);
                __ret;
            })) {
                return;
        }

The "flags = arch_local_irq_save();" and the
"arch_local_irq_restore(flags);" lines set both the true and the false
paths.  (Which we don't want.  But we generally do want assignments to
set both the true and false paths.)  So since the true and false paths were
already set (to wrong things) then it means we don't set them to their
implied values (which we are able to calculate correctly).

The problem with always setting things to their implied values even when
they have already been set is that we might have set them to a more
specific and interesting setting than is implied.

Another solution which I have not explored is that when we have a condition
you would always have a true_slist, false_slist and a both_slist.  We would
merge the both_slist manually.  The set_state() function would never set
the true and false paths.  This idea is probably the correct thing because
it means that we would not set either side to unlocked but instead we would
set it to &merged.  Which is not correct, but it's less wrong.

I think we still need this though as well.

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