[cfe-dev] Static Analyzer Checker Options Proposal

[Aleksei Sidorin]

AFAIR, my implementation has such features. If MallocChecker, for 
example, calls getCheckerOption("unix.Malloc", "Optimistic", "false"), 
it will get this option for "unix" package if it was not specified for 
the checker itself but was specified for its package.
>    
>> On Oct 13, 2014, at 8:55 AM, Gabor Kozar <kozargabor at fastmail.fm> wrote:
>>
>> However, there will be no inheritance (i.e. the setting 'unix:Optimistic' is entirely distinct from the setting ?unix.Malloc:Optimistic?).
>>   
>> I think inheritance like that could be useful in some situations.
> The main reason is that we currently do not have a need for it and allowing inheritance requires a design for it. For example, what happens when a package adds an option? How would the checkers access it? If we were to allow dynamically loaded checkers how would they inherit it? What happens if a checker overrides a package option?
>
>> I would expect such options to be inherited, i.e. if I set 'unix:Optimistic', then I expect this to be visible everywhere in the 'unix' package. Why are disallowing this?
>>   
> The package options will be visible to checkers; specifically, checkers could query the package options. For example, MallocChecker could call getOption(Optimistic, "unix") to check if the option has been set on the package.
>
>> (Sorry for the duplicate e-mail, sent the first from the wrong e-mail address.)
>>   
>> ---
>> Best regards,
>>   
>> G?bor 'ShdNx' Koz?r
>> http://gaborkozar.me <http://gaborkozar.me/>
>>   
>>   
>> On Mon, Oct 13, 2014, at 15:59, Gabor Kozar wrote:
>>> However, there will be no inheritance (i.e. the setting 'unix:Optimistic' is entirely distinct from the setting ?unix.Malloc:Optimistic?).
>>>   
>>> I think inheritance like that could be useful in some situations. I would expect such options to be inherited, i.e. if I set 'unix:Optimistic', then I expect this to be visible everywhere in the 'unix' package. Why are you proposing to disallow this?
>>>   
>>> ---
>>> Best regards,
>>>   
>>> G?bor 'ShdNx' Koz?r
>>> http://gaborkozar.me <http://gaborkozar.me/>
>>>   
>>>   
>>>   
>>> On Sat, Oct 11, 2014, at 01:17, Anna Zaks wrote:
>>>> Background & Problem:
>>>>   
>>>> Clang has support for static analyzer options though "-analyzer-config?
>>>> front-end option, which is followed by the option name and value:
>>>> -analyzer-config <Option Name>=<Value>
>>>> This option is also available through scan-build.
>>>>   
>>>> Currently, there is no way to pass command line options to specific
>>>> checkers. We work around it by creating new checker kinds (for example,
>>>> MallocPessimistic, MallocOptimistic).
>>>>   
>>>> Proposed Solution:
>>>>   
>>>> The proposal (partially authored and implemented by Aleksei Sidorin
>>>> http://reviews.llvm.org/D3967 <http://reviews.llvm.org/D3967>) is to extend "-analyzer-config" to support
>>>> checker-specific options as following:
>>>> -analyzer-config <Full Checker Name / Package Name>:<Option
>>>> Name>=<Value>
>>>>   
>>>> To avoid ambiguities with regular options, we should enforce the
>>>> following:
>>>> 1) <Option Name> should be an identifier
>>>> 2) Checker names should be identifiers.
>>>> 3) Package names should be identifiers joined with '.?.
>>>> 4) <Full Checker Name> has the same form as package names.
>>>>   
>>>> Specifying options on a package will be allowed. However, there will be
>>>> no inheritance (i.e. the setting 'unix:Optimistic' is entirely distinct
>>>> from the setting ?unix.Malloc:Optimistic?). Each checker will be able to
>>>> query options of its package when needed. For this, we propose changing
>>>> the getOption API to work with package and checker names as well as
>>>> CheckerBase.
>>>>   
>>>> Comments and suggestions are welcome!
>>>> Anna.
>>>> _______________________________________________
>>>> cfe-dev mailing list
>>>> cfe-dev at cs.uiuc.edu <mailto:cfe-dev at cs.uiuc.edu>
>>>> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev <http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev>
>>>   
>>> _______________________________________________
>>> cfe-dev mailing list
>>> cfe-dev at cs.uiuc.edu <mailto:cfe-dev at cs.uiuc.edu>
>>> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev <http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev>
>>   
>> _______________________________________________
>> 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.cs.uiuc.edu/pipermail/cfe-dev/attachments/20141013/79064a86/attachment.html>
>
> ------------------------------
>
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
>
>
> End of cfe-dev Digest, Vol 88, Issue 55
> ***************************************
>


-- 
Best regards,
Aleksei Sidorin
Software Engineer,
IMSWL-IMCG, SRR, Samsung Electronics