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

[Aemon Cannon]

To be more specific: I want to compare a file path (possibly relative), to
a list of strings and determine if any of the strings are a prefix of the
path.


On Sat, Sep 21, 2013 at 11:07 PM, Aemon Cannon <aemoncannon at gmail.com>wrote:

> 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/d80a9917/attachment.html>