FAQ and How to Deal with Common False Positives

1. How do I tell the analyzer that I do not want the bug being reported here since my custom error handler will safely end the execution before the bug is reached?
2. The analyzer reports a null dereference, but I know that the pointer is never null. How can I tell the analyzer that a pointer can never be null?
3. 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?
4. How can I suppress a specific analyzer warning?
5. How can I selectively exclude code the analyzer examines?

Q: How do I tell the analyzer that I do not want the bug being reported here since my custom error handler will safely end the execution before the bug is reached?

You can tell the analyzer that this path is unreachable by teaching it about your custom assertion handlers. For example, you can modify the code segment as following.

void customAssert() __attribute__((analyzer_noreturn));
int foo(int *b) {
  if (!b)
    customAssert();
  return *b;
}

Q: The analyzer reports a null dereference, but I know that the pointer is never null. How can I tell the analyzer that a pointer can never be null?

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 if (!b) check.

void usePointer(int *b);
int foo(int *b) {
  usePointer(b);
  return *b;
}

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?

In the contrived example above, the analyzer has detected that the body of the loop is never entered for the case where length <= 0. In this particular example, you may know that the loop will always be entered because the input parameter length will be greater than zero in all calls to this function. You can teach the analyzer facts about your code as well as document it by using assertions. By adding assert(length > 0) in the beginning of the function, you tell the analyzer that your code is never expecting a zero or a negative value, so it won't need to test the correctness of those paths.

int foo(int length) {
  int x = 0;
  assert(length > 0);
  for (int i = 0; i < length; i++)
    x += 1;
  return length/x;
}

Q: How can I suppress a specific analyzer warning?

There is currently no solid mechanism for suppressing an analyzer warning, although this is currently being investigated. When you encounter an analyzer bug/false positive, check if it's one of the issues discussed above or if the analyzer annotations can resolve the issue. Second, please report it to help us improve user experience. As the last resort, consider using __clang_analyzer__ macro described below.

Q: How can I selectively exclude code the analyzer examines?

When the static analyzer is using clang to parse source files, it implicitly defines the preprocessor macro __clang_analyzer__. One can use this macro to selectively exclude code the analyzer examines. Here is an example:

#ifndef __clang_analyzer__
// Code not to be analyzed
#endif

This usage is discouraged because it makes the code dead to the analyzer from now on. Instead, we prefer that users file bugs against the analyzer when it flags false positives.