[cfe-dev] Clang static analyzer: ignore library headers?

[Aemon Cannon]

Logistical question: does clang or llvm contain a good data-structure for
efficient string lookup by prefix?  I'm sketching out a blacklist patch
with a vector<string> at the moment.
Thanks


On Mon, Sep 16, 2013 at 2:21 PM, Anna Zaks <ganna at apple.com> wrote:

>
> On Sep 16, 2013, at 11:09 AM, Aemon Cannon <aemoncannon at gmail.com> wrote:
>
> Yes, I'm mostly interested in hiding issues from those headers
> (performance is a side benefit).
>
>
> One thing to remember is that even if you don't check the functions from
> the headers as the main entry points, you might still get issues from those
> files reported; specifically, while analyzing the functions from your
> source files that call them. Possibly, the best solution is to not analyze
> the extra functions(for performance) and suppress reports coming from the
> third party libraries as well. There is one issue though. Since the
> analyzer bugs correspond to paths, you might have a path that spans through
> your code and the third party code. There is usually no way of identifying
> which code actually causes the problem..
>
>
>
> I think it would be generally valuable to have a mode where issues coming
> from black listed libraries would be hidden. You could do it from the
> checker as I've mentioned, but you could also add an experimental (off by
> default) option to the analyzer and suppress issues inside BugReporter.
> This would make it work for all checkers.
> shouldReportIssuesInMainSourceFile is a very good example of how you
> would do that.
>
> I'll look into the approaches you suggested.
>
> Thanks very much,
> Aemon
>
>
> On Mon, Sep 16, 2013 at 2:02 PM, Anna Zaks <ganna at apple.com> wrote:
>
>> Are you mostly concerned abut performance implications of analyzing third
>> party headers?
>> One might also not want to show issues reported in those, in which case
>> the black list might also be useful.
>>
>> You could add another option to the analyzer that enables checking only
>> in the project headers. This would be similar to how !AnalyzeAll option
>> works - we just skip the functions defined in headers in AnalysisConsumer.
>> (Note, that if you just wanted to suppress the issues, you could most
>> likely do it from the checker.)
>>
>> If you are to add another option, note that we are switching to a new
>> method of defining options - you should not need to modify
>> CompilerInviocation, for example, see "shouldReportIssuesInMainSourceFile"
>> .
>>
>> Anna.
>>
>> On Sep 16, 2013, at 10:40 AM, Aemon Cannon <aemoncannon at gmail.com> wrote:
>>
>> Hi Anna,
>>
>> I would be happy with some way to specify a local blacklist. At the
>> moment,  once I enable the analyzer-header option, it doesn't seem like I
>> have any sway over which headers the checker is run over. I suspect my
>> checker is doing a lot of extra work grinding through library headers.
>>
>> (it may help to know that this is an intraprocedural analysis, so I don't
>> care about chasing arguments into libraries)
>>
>> Thanks, Aemon
>>
>>
>> On Mon, Sep 16, 2013 at 1:16 PM, Anna Zaks <ganna at apple.com> wrote:
>>
>>> We don't have a list of known third-party headers anywhere, but having
>>> this seems generally useful.
>>>
>>> Anna.
>>> On Sep 14, 2013, at 10:22 PM, Aemon Cannon <aemoncannon at gmail.com>
>>> wrote:
>>>
>>> > I'd want to enable analysis of project headers
>>> (-analyzer-opt-analyze-headers), but would like to ignore third-party
>>> library headers. Currently I have an ad hoc, in-checker, solution to this
>>> problem, but was wondering if there's an easier way. Would be nice if there
>>> was a blacklist of directories or something.
>>> >
>>> > Thanks,
>>> > Aemon
>>> > _______________________________________________
>>> > cfe-dev mailing list
>>> > cfe-dev at cs.uiuc.edu
>>> > http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
>>>
>>>
>>
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20130921/59055208/attachment.html>