[cfe-dev] Static Analyzer Checker Options Proposal

Tue Oct 14 04:32:10 PDT 2014

Ooops! In that case, my apologies!

---
Best regards,

Gábor 'ShdNx' Kozár
[1]http://gaborkozar.me

On Tue, Oct 14, 2014, at 07:52, Aleksei Sidorin wrote:

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
<[2]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

[3]http://gaborkozar.me <[4]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

[5]http://gaborkozar.me <[6]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

[7]http://reviews.llvm.org/D3967
<[8]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

[9]cfe-dev at cs.uiuc.edu <[10]mailto:cfe-dev at cs.uiuc.edu>

[11]http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
<[12]http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev>

_______________________________________________

cfe-dev mailing list

[13]cfe-dev at cs.uiuc.edu <[14]mailto:cfe-dev at cs.uiuc.edu>

[15]http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
<[16]http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev>

_______________________________________________

cfe-dev mailing list

[17]cfe-dev at cs.uiuc.edu

[18]http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev

-------------- next part --------------

An HTML attachment was scrubbed...

URL:
<[19]http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/201
41013/79064a86/attachment.html>

------------------------------

_______________________________________________

cfe-dev mailing list

[20]cfe-dev at cs.uiuc.edu

[21]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

_______________________________________________

cfe-dev mailing list

[22]cfe-dev at cs.uiuc.edu

[23]http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev

References

1. http://gaborkozar.me/
2. mailto:kozargabor at fastmail.fm
3. http://gaborkozar.me/
4. http://gaborkozar.me/
5. http://gaborkozar.me/
6. http://gaborkozar.me/
7. http://reviews.llvm.org/D3967
8. http://reviews.llvm.org/D3967
9. mailto:cfe-dev at cs.uiuc.edu
  10. mailto:cfe-dev at cs.uiuc.edu
  11. http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
  12. http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
  13. mailto:cfe-dev at cs.uiuc.edu
  14. mailto:cfe-dev at cs.uiuc.edu
  15. http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
  16. http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
  17. mailto:cfe-dev at cs.uiuc.edu
  18. http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
  19. http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20141013/79064a86/attachment.html
  20. mailto:cfe-dev at cs.uiuc.edu
  21. http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
  22. mailto:cfe-dev at cs.uiuc.edu
  23. 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/20141014/4b7a1278/attachment.html>