1<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" 2 "http://www.w3.org/TR/html4/strict.dtd"> 3<html> 4<head> 5 <title>FAQ and How to Deal with Common False Positives</title> 6 <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"> 10 tr:first-child { width:20%; } 11 </style> 12</head> 13<body> 14 15<div id="page"> 16<!--#include virtual="menu.html.incl"--> 17 18<div id="content"> 19 20<h1>FAQ and How to Deal with Common False Positives</h1> 21 22<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> 31 <li><a href="#exclude_code">How can I selectively exclude code the analyzer examines?</a></li> 32</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 36reported here since my custom error handler will safely end the execution before 37the bug is reached?</h4> 38 39<img src="images/example_custom_assert.png" alt="example custom assert"> 40 41<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> 42 43<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 53pointer is never null. How can I tell the analyzer that a pointer can never be 54null?</h4> 55 56<img src="images/example_null_pointer.png" alt="example null pointer"> 57 58<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> 59 60<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> 68 69<img src="images/example_use_assert.png" alt="example use assert"> 70 71<p> In the contrived example above, the analyzer has detected that the body of 72the loop is never entered for the case where <tt>length <= 0</tt>. In this 73particular example, you may know that the loop will always be entered because 74the input parameter <tt>length</tt> will be greater than zero in all calls to this 75function. You can teach the analyzer facts about your code as well as document 76it by using assertions. By adding <tt>assert(length > 0)</tt> in the beginning 77of the function, you tell the analyzer that your code is never expecting a zero 78or a negative value, so it won't need to test the correctness of those paths. 79</p> 80 81<pre class="code_example"> 82int foo(int length) { 83 int x = 0; 84 <span class="code_highlight">assert(length > 0);</span> 85 for (int i = 0; i < length; i++) 86 x += 1; 87 return length/x; 88} 89</pre> 90 91<h4 id="suppress_issue" class="faq">Q: How can I suppress a specific analyzer warning?</h4> 92 93<p>There is currently no solid mechanism for suppressing an analyzer warning, 94although this is currently being investigated. When you encounter an analyzer 95bug/false positive, check if it's one of the issues discussed above or if the 96analyzer <a href = "annotations.html#custom_assertions" >annotations</a> can 97resolve the issue. Second, please <a href = "filing_bugs.html">report it</a> to 98help us improve user experience. As the last resort, consider using <tt>__clang_analyzer__</tt> macro 99<a href = "faq.html#exclude_code" >described below</a>.</p> 100 101<h4 id="exclude_code" class="faq">Q: How can I selectively exclude code the analyzer examines?</h4> 102 103<p>When the static analyzer is using clang to parse source files, it implicitly 104defines the preprocessor macro <tt>__clang_analyzer__</tt>. One can use this 105macro to selectively exclude code the analyzer examines. Here is an example: 106 107<pre class="code_example"> 108#ifndef __clang_analyzer__ 109// Code not to be analyzed 110#endif 111</pre> 112 113This usage is discouraged because it makes the code dead to the analyzer from 114now on. Instead, we prefer that users file bugs against the analyzer when it flags 115false positives. 116</p> 117 118</div> 119</div> 120</body> 121</html> 122 123
