]> granicus.if.org Git - clang/commitdiff
Make "important notes" more succinct.
authorTed Kremenek <kremenek@apple.com>
Tue, 17 Jun 2008 06:47:58 +0000 (06:47 +0000)
committerTed Kremenek <kremenek@apple.com>
Tue, 17 Jun 2008 06:47:58 +0000 (06:47 +0000)
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@52388 91177308-0d34-0410-b5e6-96231b3b80d8

www/StaticAnalysis.html

index f15d0d47ba1a94f16111236e5a76e161f2440de2..0444f0d12b503ff68ad5bef36192952b440d9987 100644 (file)
@@ -25,24 +25,19 @@ analyzer:</p>
 enhancements to improve both the precision and scope of its analysis algorithms
 as well as the kinds bugs it will find.</li>
 
-<li><b>False positives.</b> Static analysis reasons about the run-time behavior
-of a program without actually running the program. Static analysis is not
-perfect, and can falsely flag bugs in a program where the code behaves
-correctly. Because some code checks performed by the analyzer require more
-analysis than others, the frequency of false positives can vary widely between
-different checks. Our goal is to have the analyzer have a low false positive
-rate for most code on all checks, and we will reach this goal by gradually
-improving over time the analysis precision of the tool.</li>
-
-<li><b>Static analysis can be much slower than compilation.</b> The analyzer
-performs a variety of checks on code, each requiring different levels of
-analysis precision (more precision = more CPU time). While the analyzer is being
-designed to be as fast and light-weight as possible, please do not expect it to
-be as fast as compiling a program (even with optimizations enabled). Some of the
-algorithms needed to find bugs require in the worst case exponential time. The
-analyzer runs in a reasonable amount of time by both bounding the amount of
-checking work it will do as well as using clever algorithms to reduce the amount
-of work it must do to find bugs.</li>
+<li><b>False positives.</b> Static analysis is not perfect. It can falsely flag
+bugs in a program where the code behaves correctly. Because some code checks
+require more analysis precision than others, the frequency of false positives
+can vary widely between different checks. Our eventual goal is to have the
+analyzer have a low false positive rate for most code on all checks.</li>
+
+<li><b>Static analysis can be much slower than compilation.</b> While the
+analyzer is being designed to be as fast and light-weight as possible, please do
+not expect it to be as fast as compiling a program (even with optimizations
+enabled). Some of the algorithms needed to find bugs require in the worst case
+exponential time. The analyzer runs in a reasonable amount of time by both
+bounding the amount of checking work it will do as well as using clever
+algorithms to reduce the amount of work it must do to find bugs.</li>
 
 </ul>