Static Analysis
Static analysis is the analysis of a computer program without actually
executing the program. (Static analysis differs from dynamic analysis in that
the latter focuses on the behavior of the program while it is running.)
Although perfect analysis is impossible (non-trivial properties of programs are
undecidable according to Rice’s theorem), many mistakes follow patterns
that are relatively easy to detect. For example, setting a pointer to null
and then immediately dereferencing that pointer is never correct.
Perhaps surprisingly given the prevalence of bugs (i.e., faults) in real-world software, many mistakes can be found automatically. This exercise compares various tools that exist for this purpose, from enabling compiler warnings to “bug checkers” designed to identify null pointer dereferences, memory leaks, undefined behavior, and dangerous coding constructs. It should be noted that these tools are typically unsound (i.e., may not find every fault) and incomplete (i.e., some warnings may not be actual faults) as a consequence of Rice’s theorem, but much work goes into minimizing the number of false positives.
Help Policy
- Authorized Resources
- Any, including classmates
- Notes
- Because this activity builds on an assignment from another course, you are not permitted to discuss it outside this class. That is, both the original assignment and this exercise are under academic security (indefinitely).
Instructions
Use the GitHub Classroom link (distributed separately) to access the source code for this exercise. When you accept the assignment, be sure to join the existing group (“students”) so that you use the existing repository and have access to the existing continuous integration (CI) build logs.
Access the continuous integration (CI) log for each job in the build. When viewing the project on GitHub, click “commits” on the Code tab. You will see either a green check mark (build passed), red x mark (build failed), or yellow circle (build in progress). Click the icon, and click “Details” on the pop-up. You can access the build log for each job by clicking on the job number (format: x.y where x is the build number and y is the job number within the build) under the build details.
Answer the following questions:
-
How many warnings were reported by each compiler (GCC and Clang)?
-
What were the warnings reported by each compiler?
-
What issues does Cppcheck report?
-
What issues does Infer report?
-
Which of the prior warnings and issues appear to be faults (i.e., implementation mistakes)? Which appear to be spurious?