blob: 5c132b57f2e5c8ecf46bf427f163487bc0d6ae0b [file] [log] [blame]
Anna Zaks568bdee2012-06-09 01:04:54 +00001<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
2 "http://www.w3.org/TR/html4/strict.dtd">
3<html>
4<head>
Anna Zaks70186fc2012-06-09 01:05:01 +00005 <title>FAQ and How to Deal with Common False Positives</title>
Anna Zaks568bdee2012-06-09 01:04:54 +00006 <link type="text/css" rel="stylesheet" href="menu.css">
7 <link type="text/css" rel="stylesheet" href="content.css">
8 <script type="text/javascript" src="scripts/menu.js"></script>
9 <style type="text/css">
Ted Kremenekdea37f22012-06-09 20:10:45 +000010 tr:first-child { width:20%; }
Anna Zaks568bdee2012-06-09 01:04:54 +000011 </style>
12</head>
13<body>
14
15<div id="page">
16<!--#include virtual="menu.html.incl"-->
17
18<div id="content">
19
Ted Kremenekc1cb12b2012-06-09 20:10:42 +000020<h1>FAQ and How to Deal with Common False Positives</h1>
Anna Zaks568bdee2012-06-09 01:04:54 +000021
Anna Zakse06f5a02012-06-11 22:09:44 +000022<ol>
23 <li><a href="#custom_assert">How do I tell the analyzer that I do not want the bug being
24reported here since my custom error handler will safely end the execution before
25the bug is reached?</a></li>
26 <li><a href="#null_pointer">The analyzer reports a null dereference, but I know that the
27pointer is never null. How can I tell the analyzer that a pointer can never be
28null?</a></li>
29 <li><a href="#use_assert">The analyzer assumes that a loop body is never entered. How can I tell it that the loop body will be entered at least once?</a></li>
30 <li><a href="#suppress_issue">How can I suppress a specific analyzer warning?</a></li>
Anna Zaks843f0e82012-06-16 00:30:21 +000031 <li><a href="#exclude_code">How can I selectively exclude code the analyzer examines?</a></li>
Anna Zakse06f5a02012-06-11 22:09:44 +000032</ol>
33
34
35<h4 id="custom_assert" class="faq">Q: How do I tell the analyzer that I do not want the bug being
Ted Kremenekdea37f22012-06-09 20:10:45 +000036reported here since my custom error handler will safely end the execution before
37the bug is reached?</h4>
Anna Zaks568bdee2012-06-09 01:04:54 +000038
39<img src="images/example_custom_assert.png" alt="example custom assert">
40
Anna Zakse06f5a02012-06-11 22:09:44 +000041<p>You can tell the analyzer that this path is unreachable by teaching it about your <a href = "annotations.html#custom_assertions" >custom assertion handlers</a>. For example, you can modify the code segment as following.</p>
Anna Zaks568bdee2012-06-09 01:04:54 +000042
Anna Zakse06f5a02012-06-11 22:09:44 +000043<pre class="code_example">
44void customAssert() <span class="code_highlight">__attribute__((analyzer_noreturn))</span>;
45int foo(int *b) {
46 if (!b)
47 customAssert();
48 return *b;
49}</pre>
50
51
52<h4 id="null_pointer" class="faq">Q: The analyzer reports a null dereference, but I know that the
Ted Kremenekdea37f22012-06-09 20:10:45 +000053pointer is never null. How can I tell the analyzer that a pointer can never be
54null?</h4>
Anna Zaks568bdee2012-06-09 01:04:54 +000055
56<img src="images/example_null_pointer.png" alt="example null pointer">
57
Ted Kremenekdea37f22012-06-09 20:10:45 +000058<p>The reason the analyzer often thinks that a pointer can be null is because the preceding code checked compared it against null. So if you are absolutely sure that it cannot be null, remove the preceding check and, preferably, add an assertion as well. For example, in the code segment above, it will be sufficient to remove the <tt>if (!b)</tt> check. </p>
Anna Zaks568bdee2012-06-09 01:04:54 +000059
Anna Zakse06f5a02012-06-11 22:09:44 +000060<pre class="code_example">
61void usePointer(int *b);
62int foo(int *b) {
63 usePointer(b);
64 return *b;
65}</pre>
66
67<h4 id="use_assert" class="faq">Q: The analyzer assumes that a loop body is never entered. How can I tell it that the loop body will be entered at least once?</h4>
Anna Zaks568bdee2012-06-09 01:04:54 +000068
69<img src="images/example_use_assert.png" alt="example use assert">
70
Ted Kremenekdea37f22012-06-09 20:10:45 +000071<p>You can teach the analyzer facts about your code as well as document it by
72using assertions. In the contrived example above, the analyzer reports an error
73on the path which assumes that the loop is never entered. However, the owner of
74the code might know that the loop is always entered because the input parameter
75<tt>length</tt> is always greater than <tt>0</tt>. The false positive can be
76suppressed by asserting this knowledge, adding <tt>assert(length > 0)</tt> in
77the beginning of the function.</p>
Anna Zaks568bdee2012-06-09 01:04:54 +000078
Anna Zakse06f5a02012-06-11 22:09:44 +000079<pre class="code_example">
80int foo(int length) {
81 int x = 0;
82 <span class="code_highlight">assert(length > 0);</span>
83 for (int i = 0; i < length; i++)
84 x += 1;
85 return length/x;
86}
87</pre>
Anna Zaks568bdee2012-06-09 01:04:54 +000088
Anna Zakse06f5a02012-06-11 22:09:44 +000089<h4 id="suppress_issue" class="faq">Q: How can I suppress a specific analyzer warning?</h4>
Anna Zaks568bdee2012-06-09 01:04:54 +000090
Anna Zaks843f0e82012-06-16 00:30:21 +000091<p>There is currently no solid mechanism for suppressing an analyzer warning,
92although this is currently being investigated. When you encounter an analyzer
93bug/false positive, check if it's one of the issues discussed above or if the
94analyzer <a href = "annotations.html#custom_assertions" >annotations</a> can
95resolve the issue. Second, please <a href = "filing_bugs.html">report it</a> to
96help us improve user experience. As the last resort, consider using <tt>__clang_analyzer__</tt> macro
97<a href = "faq.html#exclude_code" >described below</a>.</p>
98
99<h4 id="exclude_code" class="faq">Q: How can I selectively exclude code the analyzer examines?</h4>
100
101<p>When the static analyzer is using clang to parse source files, it implicitly
102defines the preprocessor macro <tt>__clang_analyzer__</tt>. One can use this
103macro to selectively exclude code the analyzer examines. Here is an example:
104
105<pre class="code_example">
106#ifndef __clang_analyzer__
107// Code not to be analyzed
108#endif
109</pre>
110
111This usage is discouraged because it makes the code dead to the analyzer from
112now on. Instead, we prefer that users file bugs against the analyzer when it flags
113false positives.
114</p>
Anna Zaks568bdee2012-06-09 01:04:54 +0000115
116</div>
117</div>
118</body>
119</html>
120