[cfe-dev] Purpose of GenericTaintChecker

[Artem Dergachev via cfe-dev]

The analyzer analyzes every statement in the CFG, first calling 
checkPreStmt for it, then "executing" the statement, then calling 
checkPostStmt. The "executing" phase may include other callbacks, such 
as checkBind or checkPreCall/checkPostCall. CFG terminators, such as 
`if()` or `for()` or `?:` or `&&`, are not covered with 
checkPreStmt/checkPostStmt, but with checkBranchCondition.

If you want to observe how taint flows, you can enable the 
debug.TaintTest checker - it warns on all expressions values of which 
are tainted.

If it's still not obvious how GenericTaintChecker operates, you can have 
a look at its unit tests in (test/Analysis/taint-generic.c) and try to 
figure out how's that different with your case. Like, gets() itself 
isn't a bug, so no warning here; but system(gets()) is already suspicious.

Yeah, taint information is the same for all checkers: if 
GenericTaintChecker is enabled, other checkers would see symbols marked 
by it as tainted as tainted.

In any case, i encourage you to share more details on what you're doing, 
because i've no way of guessing what subtle misunderstanding may be 
blocking you. Eg., you may be confusing value of the symbolic pointer 
and symbolic value behind that pointer, which is very easy to mess up 
when working with symbols before you collect some intuition/experience, 
or something like that, there may be a lot of problems when you just 
start. Since the previous thread, i finally published some guide for 
beginners 
(https://github.com/haoNoQ/clang-analyzer-guide/releases/download/v0.1/clang-analyzer-guide-v0.1.pdf) 
- though it doesn't contain much on taint (we're already past it, worth 
improving i guess), it might save some time on understanding the ideas 
behind the analyzer.

Another problem you might have encountered - why you don't see taint on 
a CallExpr instantly - is because there's a race between your checker 
and GenericTaintChecker, both of which are subscribing on 
check::PostStmt<CallExpr>. Order of calling different checkers on the 
same callback is currently undefined (though we realize that it's a good 
idea to create dependencies between checkers). Most of the time it 
doesn't matter though, because one usually catches tainted values on 
checkPreStmt's. But i've no way of guessing if that's what you're doing.