[PATCH] check for Incorrect logic in operator

Anna Zaks ganna at apple.com
Wed Oct 30 11:24:40 PDT 2013

On Oct 30, 2013, at 9:28 AM, Jordan Rose <jordan_rose at apple.com> wrote:

> On Oct 29, 2013, at 19:14 , Richard Trieu <rtrieu at google.com> wrote:
>> With these points in mind, are there particular concerns about cases where the “CFG won’t check all the code a Sema based warning would”.  If you addressed the last point, I think you’d pretty much get the coverage that you want.  What do you think?
>> I think that globals and global initializers are not represented in the CFG.  That's my main concern about using only the CFG at the moment.
> I don't think it would be difficult to build a CFG from a single global initializer (or member initializer). No one's done it yet, but I don't think that means it can't be done.
> On the more general issue I can see both sides: avoiding extra walks over the AST or CFG is good, knowing what's trivially dead code is good (except when it isn't), and not conflating concerns is good.
> For these particular checks, though (and I haven't looked at the patch, just the checks), I think they are fundamentally syntactic checks, not flow-sensitive ones, and that we will actually get little benefit out of using this information to improve the CFG.

We are still constructing a CFG after reporting these warnings, so it would be beneficial to feed the output of these checks into CFG construction. This way the CFG and CFG based warnings(and static analyzer checks) will be consistent with these warnings. Also, we could possibly extend the warning to show a note on code which becomes unreachable along with the diagnostic and extend it to cover more intricate flow sensitive cases in the future. 

If we can add the analysis of globals, there is no downside of performing the checks when we build the CFG as far as I can tell. Not sure if there are performance implications - do we always build the CFG?

> Each case is warning about a likely-incorrect boolean expression, which implies that if the user fixed the expression we could easily get a different CFG. That doesn't help answer questions of general policy, but it might at least untangle this patch from the discussion.
> Jordan
> _______________________________________________
> cfe-commits mailing list
> cfe-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20131030/d0e0ce4d/attachment.html>

More information about the cfe-commits mailing list