[cfe-dev] [analyzer] Thoughts on Temporary Destructors

[Manuel Klimek]

On Mon, Feb 24, 2014 at 10:49 PM, Anna Zaks <ganna at apple.com> wrote:

> Is it possible to have the same (similar) positive results just by
> teaching the analyzer about the custom assertions? If yes, I’d suggest you
> to use that as a patch on your private branch. Or you might consider
> teaching the TOT analyzer to accept a list of such assertions. This could
> be used in cases the source code cannot be annotated with ‘noreturn'.
>
> As Jordan and Ted had mentioned, just reverting the patch results in
> unexpected behavior in both ObjC and C++.
> See cfe/trunk/test/Analysis/live-variables.cpp for the C++ example. There,
> even though the dereference of 'p’ is guarded by ‘p != 0’, we reported a
> null pointer dereference.
>

Hi Anna,

thx for the tip; we'll basically evaluate each warning on its own (we want
> 90% true positive rate) and see how far we can get without needing to
patch, or which warnings the patch affects in which ways.

Cheers,
/Manuel


>
> Anna.
>
> On Feb 10, 2014, at 2:38 AM, Daniel Connelly <dconnelly at google.com> wrote:
>
> (cc: klimek at google.com, djasper at google.com)
>
> As a bit of a follow-up, we are still very interested in getting this
> worked out, as it's a significant barrier to the Analyzer's usefulness. All
> of our C++ projects make extensive use of custom assertions. For example,
>
> CHECK(condition) << "something happened with the hydrospanners";
>
> which logs a message and kills the program if the condition isn't met.
> None of these custom assertions are pruning code paths due to the missing
> conditional expression support. For example, when building Chromium, the
> difference between running without and with the reverted patch is 1982
> reported errors vs. 3210 reported errors. This number is a bit
> conservative, since we also have this problem in dependent libraries that
> don't (but could) use analyzer_noreturn on their assertions; the real cost
> is that about 50% of all errors reported by the analyzer are false
> positives of this form.
>
>
> On Fri, Jan 31, 2014 at 11:32 AM, Daniel Connelly <dconnelly at google.com>wrote:
>
>> After digging into this for a couple of weeks across the 2013/2014
>> boundary, I now doubt that my 20% time will be enough to properly implement
>> this support. Anybody who's interested should feel free to work on this
>> instead, as I'll not be moving forward with it. Jordan, thanks for the
>> pointers and the summary of the problem!
>>
>>
>> On Wed, Dec 18, 2013 at 1:55 AM, Jordan Rose <jordan_rose at apple.com>wrote:
>>
>>>
>>> On Dec 16, 2013, at 6:57 , Daniel Connelly <dconnelly at google.com> wrote:
>>>
>>> On Fri, Dec 13, 2013 at 7:13 PM, Jordan Rose <jordan_rose at apple.com>wrote:
>>>
>>>>
>>>> In discussing the first problem, Ted and Anna realized that the
>>>> liveness information for nested && and || expressions was still incorrect:
>>>> the outermost expression may potentially depend on all of the inner
>>>> expressions, but that means that those sub-expressions are *always* considered
>>>> live (since expressions are marked dead, in a reverse analysis, at the
>>>> point of evaluation, and there are paths that don't evaluate a particular
>>>> sub-expression in a complex logical expression). This wasn't an issue
>>>> before because && and || didn't actually use those expressions to compute
>>>> their value, but it's still incorrect.
>>>>
>>>
>>> Is this http://llvm.org/bugs/show_bug.cgi?id=18159 ?
>>>
>>>
>>> Yes.
>>>
>>> Thanks for the overview. This is all pretty new to me, so I'm going to
>>> dig into the problem for a couple of days and hopefully come up with some
>>> intelligent questions.
>>>
>>>
>>> Sorry for the blast of information. If you want an easier place to start
>>> playing with the analyzer, you could try hacking on productizing
>>> SimpleStreamChecker. (And if you haven't watched our talk from last year's
>>> LLVM dev meeting, I definitely suggest taking the time to do so. It's aimed
>>> at checker writers, but still describes the general structure of the
>>> analyzer. It's linked near the top of
>>> http://clang-analyzer.llvm.org/checker_dev_manual.html)
>>>
>>> Jordan
>>>
>>
>>
>>
>> --
>> Daniel Connelly | Software Engineer – Chrome | dconnelly at google.com |
>>
>> Google Germany GmbH
>> Dienerstr. 12
>> 80331 München
>>
>> Registergericht und -nummer: Hamburg, HRB 86891
>> Sitz der Gesellschaft: Hamburg
>> Geschäftsführer: Graham Law, Christine Elizabeth Flores
>>
>>
>
>
> --
> Daniel Connelly | Software Engineer – Chrome | dconnelly at google.com |
>
> Google Germany GmbH
> Dienerstr. 12
> 80331 München
>
> Registergericht und -nummer: Hamburg, HRB 86891
> Sitz der Gesellschaft: Hamburg
> Geschäftsführer: Graham Law, Christine Elizabeth Flores
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20140225/3ca4af90/attachment.html>