There is an open radar to implement better scanf checking as a Sema warning. However, a bit of redundancy is fine in this case.

llvm-svn: 144964

When the solver and SValBuilder cannot reason about symbolic expressions (ex: (x+1)*y ), the analyzer conjures a new symbol with no ties to the past. This helps it to recover some path-sensitivity. However, this breaks the taint propagation.

With this commit, we are going to construct the expression even if we cannot reason about it later on if an operand is tainted.

Also added some comments and asserts.

llvm-svn: 144932

llvm-svn: 144928

Naming could be improved.. But we should first rename the classes in the SVal hierarchy.

llvm-svn: 144927

llvm-svn: 144871

llvm-svn: 144870

Manager. Added test to ensure proper binding of initialized values.
This patch fixes PR11249.

llvm-svn: 144831

llvm-svn: 144829

Change the ArrayBoundCheckerV2 to be more aggressive in reporting buffer overflows
when the offset is tainted. Previously, we did not report bugs when the state was
underconstrained (not enough information about the bound to determine if there is
an overflow) to avoid false positives. However, if we know that the buffer
offset is tainted - comes in from the user space and can be anything, we should
report it as a bug.

+ The very first example of us catching a taint related bug.
This is the only example we can currently handle. More to come...

llvm-svn: 144826

The checker is responsible for defining attack surface and adding taint to symbols.

llvm-svn: 144825

TaintTag.h will contain definitions of different taint kinds and their properties.
TaintManager will be responsible for implementing taint specific operations, storing taint.
ProgramState will provide API to add/remove taint.

llvm-svn: 144824

llvm-svn: 144823

many checkers are trying to get a name of the callee when visiting
a CallExpr, so provide a convenience API.

llvm-svn: 144820

[static analyzer] Tweak RetainCountChecker's diagnostics to correctly indicate if a message was due to a property access.  This can
potentially be refactored for other clients, and this is a regression from the refactoring of property acceses.

llvm-svn: 144571

[analyzer;Regionstore] handle loads from StringLiteral elements for StringLiterals representing wide strings.  Fixes PR 11294.

llvm-svn: 144563

[static analyzer] be more specific when running removeDeadBindings.  Instead of seeing if the predecessor node was a non-StmtPoint, check if it is specifically a BlockEntrance node.

llvm-svn: 144340

[static analyzer]: only call RemoveDeadBindings() when analyzing non-Expr stmts, entering a basic block, or analyzing non-consumed expressions.  This sigificantly speeds up analysis time, and reduces analysis time down to 27% less than before we linearized the CFG.

llvm-svn: 144332

literal types, as well as derived-to-base casts for lvalues and
derived-to-virtual-base casts.

llvm-svn: 144265

Analysis by Ted:
"
    if (stateZero && !stateNotZero) {

is checking to see if:

  (A)  "it is possible for the value to be zero"   (stateZero)

    AND

  (B) "it is not possible for the value to be non-zero"  (!stateNotZero)

That said, the only way for both B to be true AND A to be false is if the path is completely infeasible by the time we reach the divide-by-zero check.  For the most part (all cases?), such cases should automatically get pruned out at branches (i.e., an infeasible path gets dropped), which is the case in our tests.  So the question is whether or not such an infeasible path might not get dropped earlier?  I can't envision any right now.

Indeed, the rest of the checker assumes that if the bug condition didn't fire then 'stateNotZero' is non-NULL:

    C.addTransition(stateNotZero);
"

llvm-svn: 144114

llvm-svn: 143910

property references to use a new PseudoObjectExpr
expression which pairs a syntactic form of the expression
with a set of semantic expressions implementing it.
This should significantly reduce the complexity required
elsewhere in the compiler to deal with these kinds of
expressions (e.g. IR generation's special l-value kind,
the static analyzer's Message abstraction), at the lower
cost of specifically dealing with the odd AST structure
of these expressions.  It should also greatly simplify
efforts to implement similar language features in the
future, most notably Managed C++'s properties and indexed
properties.

Most of the effort here is in dealing with the various
clients of the AST.  I've gone ahead and simplified the
ObjC rewriter's use of properties;  other clients, like
IR-gen and the static analyzer, have all the old
complexity *and* all the new complexity, at least
temporarily.  Many thanks to Ted for writing and advising
on the necessary changes to the static analyzer.

I've xfailed a small diagnostics regression in the static
analyzer at Ted's request.

llvm-svn: 143867

llvm-svn: 143787

llvm-svn: 143696

Ahmed Charles!

llvm-svn: 143569

llvm-svn: 143538

This prevents caching out on nodes with different sink flag.
(This is a cleaner fix for radar://10376675).

llvm-svn: 143517

This is another fallout from the refactoring. We were
calling MarkAsSink on a cached out node.
(Fixes radar://10376675)

llvm-svn: 143516

The parent and child builders should not share node sets.

llvm-svn: 143515

This fixes radar://10367606

llvm-svn: 143514

Remove unnecessary calls to CheckerContext::getPredecessor() + Comments.

llvm-svn: 143513

llvm-svn: 143512

implicitly perform an lvalue-to-rvalue conversion if used on an lvalue
expression. Also improve the documentation of Expr::Evaluate* to indicate which
of them will accept expressions with side-effects.

llvm-svn: 143263

[analyzer] ObjC message sends to nil receivers that return structs are now okay (compiler zeroes out the data).  Fixes <rdar://problem/9151319>.

llvm-svn: 143215

llvm-svn: 143090

Enqueue the nodes generated as the result of processing a statement
inside the Core Engine. This makes sure ExpEngine does not access
CoreEngine's private members and is more concise.

llvm-svn: 143089

CheckerContext::getPredecessor is only used to get to the LocationContext
half of the times.

llvm-svn: 143061

The path sensitive checkers should use EmitBasicReport, which provides the
node information.

llvm-svn: 143060

Also document addTransition methods.

llvm-svn: 143059

Remove GenericNodeBuilder and use a class inherited from NodeBuilder instead.

llvm-svn: 143057

A step toward making sure that diagnostics report should only
be generated though the CheckerContext and not though BugReporter
or ExprEngine directly.

llvm-svn: 142947