Does clang analyzer can only report one warning?

Clang Frontend
1

Hi, all

I just want to use clang static analyzer, the command is : “clang --analyze xxx.c” to check xxx.c’s errors. but I can only see one warning message,
for example, one variable is undefined, but there exists another null pointer dereference error after that, why the analyzer can not report null pointer deference warning? Do I miss dothing sth.(e.g. one or more options needed)? or clang analyzer can only report one warning message in one function?
In other words, How clang analyzer deal with different source errors? To one kind of errors, just report the first one? or To all kind of errors, just report the first one?

Thanks.
J Green

2

For some bugs, such as uses of uninitialized variables or a null dereference, the analyzer stops analyzing a given path because the semantics would potentially be meaningless after the point of the bug. If the second bug is dominated by one of these other fail stop bugs, it won't be reported until the other bug is resolved. It's a tradeoff; the idea is that people will fix issues, run the analyzer again and uncover new ones, etc.

3

Hi, Ted
First of all, thank for your quick reply.
But I still puzzled for such case: if there exists several same kind of bugs, such as uninitialized variables, for example, a and b is two uninitialized variables, they do not have any relationship (they are in different paths), would they be reported by clang at the same time(give two uninitialized warning messages at the same time)?

Thanks again.

2010/11/19 Ted Kremenek <kremenek@apple.com>

4

p.s.
Whether there exists some options to set after command: "clang --analyze " (i.e. clang --analyze -option_a -option_b? or use scan-build command?)to let analyzer show different sources warning messages at the same time?

2010/11/21 J Green <greenabc99@gmail.com>

5

The ‘–analyze’ option is a convenience option to run the analyzer with a default set of checks. It’s main client (currently) is Xcode, but it can be used by whomever.

More specific checks can be enabled using the low-level ‘-cc1’ options, e.g.:

$ clang -cc1 -help | grep analyze

-analyze-function
-analyzer-check-dead-stores
-analyzer-check-idempotent-operations
-analyzer-check-llvm-conventions
-analyzer-check-objc-mem
-analyzer-check-objc-methodsigs
-analyzer-check-objc-missing-dealloc
-analyzer-check-objc-unused-ivars
-analyzer-check-security-syntactic
-analyzer-constraints
-analyzer-display-progress

…

It’s instructive to look at what low-level options ‘–analyze’ would run by adding -### to the end of the command line, e.g.:

$ clang --analyze foo.c -###

Apple clang version 2.0 (trunk 119338) (based on LLVM 2.9svn)
Target: x86_64-apple-darwin10
Thread model: posix
“/Developer/usr/bin/clang” “-cc1” “-triple” “x86_64-apple-darwin10.0.0” “-analyze” “-disable-free” “-disable-llvm-verifier” “-main-file-name” “foo.c” “-analyzer-store=region” “-analyzer-opt-analyze-nested-blocks” “-analyzer-check-dead-stores” “-analyzer-check-objc-mem” “-analyzer-eagerly-assume” “-analyzer-check-objc-methodsigs” “-analyzer-check-objc-unused-ivars” “-analyzer-check-idempotent-operations” “-analyzer-output” “plist” “-w” “-pic-level” “1” “-mdisable-fp-elim” “-masm-verbose” “-munwind-tables” “-target-cpu” “core2” “-target-linker-version” “97.14” “-resource-dir” “/Developer/usr/bin/…/lib/clang/2.0” “-ferror-limit” “19” “-fmessage-length” “362” “-stack-protector” “1” “-fblocks” “-fdiagnostics-show-option” “-fcolor-diagnostics” “-o” “foo.plist” “-x” “c” “foo.c”

Note that the low-level analyzer options are all subject to change. We have not stabilized an option set for the analyzer yet.

6

Yes, multiple bugs can be reported. For example:

$ cat test.c
void test(int flag) {
int *a, *b;
if (flag)
*a = 1;
else
*b = 1;
}

$ clang --analyze test.c
test.c:4:4: warning: Dereference of undefined pointer value
*a = 1;
^
test.c:6:4: warning: Dereference of undefined pointer value
*b = 1;
^
2 warnings generated.

However, if I had wrote the code as follows, only one is reported:

$ cat test2.c
void test(int flag) {
int *a, *b;
*a = 1;
*b = 1;
}

$ clang --analyze test2.c
test2.c:3:3: warning: Dereference of undefined pointer value
*a = 1;
^
1 warning generated.

In the second case, the use of ‘a’ would constitute a fail-stop bug along the path, so further analysis is meaningless. Contrast this with the GCC’s -Wuninitialized warning (which clang will also eventually support):

$ gcc -Wuninitialized -O2 test2.c
test2.c: In function ‘test’:
test2.c:3: warning: ‘a’ is used uninitialized in this function
test2.c:4: warning: ‘b’ is used uninitialized in this function

In GCC’s case, it is doing a simple dataflow analysis that doesn’t take into account value or path-dependencies, so it flags both issues. There’s tradeoffs here; with the static analyzer, one will eventually find the second bug by fixing the first one, but it gets more reliable path results by doing the pruning.