[cfe-dev] [analyzer] MallocChecker & checker dependencies

[Aleksei Sidorin via cfe-dev]

Hi Alexey!

Could you share your ideas of checker design? It is possible that 
problems you met can be solved in different (maybe even better) way if 
we know the whole picture.
Regarding your questions, you can find some answers below.

1. a) The first way for checker communication is to share their program 
state trait. You can see an example of how state trait is exported in 
GenericTaintChecker or MPIChecker. Generally, you just create a named 
ProgramStateTrait in the header. You can take a look at TaintManager.h 
and MPITypes.h and how they are used.
b) To set a dependency from another checker, you can just register it 
while registering your checker. An example can be found in MallocChecker 
where register$Checker also calls registerCStringCheckerBasic to 
register a checker it depends on.
As you pointed, inter-checker communication can become a source of some 
problems. Most of them are discussed in this conversation: 
http://clang-developers.42468.n3.nabble.com/analyzer-RFC-Design-idea-separate-modelling-from-checking-td4059122.html

2. I think there is nothing bad in sharing RegionState across checkers 
in the way shown in 1a.

3. Artem Dergachev has done some excellent work on improvement of 
operator 'new' processing in CSA engine. Regarding checkers, I can see 
some on https://clang-analyzer.llvm.org/potential_checkers.html: for 
example, undefbehavior.AutoptrsOwnSameObj. You can search this list to 
find more.


15.03.2018 23:54, Alexey Knyshev via cfe-dev пишет:
> Hi there!
>
> While thinking about how it would be possible to implement various 
> smart ptr related checkers I tried to review current state of 
> MallocChecker and came up with that it would be great to have 
> RegionState info available to other checkers. Could you please share 
> your points of view and comments on the following statements / questions:
>
> 1. Is there any right way for chaining checkers? How they are expected 
> to communicate between each other (excluding generation of nodes / 
> ProgramStates). I've heard that there are couple of problems caused by 
> inlining functions, constructors / descructors.
> 2. What do you think about moving RegionState to the Core of CSA or 
> providing optional extended info in MemRegion about the source of such 
> region (new opearator / array new, malloc, alloca, etc). So it would 
> be available to all checkers.
> 3. Is there any roadmap for CSA and especially for dynamic memory 
> management modeling & related checkers?
>
> Regards, Alexey K
>
> -- 
> linkedin.com/profile 
> <https://www.linkedin.com/profile/view?id=AAMAABn6oKQBDhBteiQnWsYm-S9yxT7wQkfWhSw>
>
> github.com/alexeyknyshev <http://github.com/alexeyknyshev>
> bitbucket.org/alexeyknyshev <https://bitbucket.org/alexeyknyshev/>
>
>
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev


-- 
Best regards,
Aleksei Sidorin,
SRR, Samsung Electronics

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20180316/c521cbba/attachment.html>