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.

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.

Answer the following questions:

  1. How many warnings were reported by each compiler (GCC and Clang)?

    • GCC: 0 warnings
    • Clang: 8 warnings total (3 in CountedMap.c and 5 in WordCloud.c)

  2. What were the warnings reported by each compiler?

    GCC does not report any warnings.

    Clang warnings:

    File Line Warning
    CountedMap.c 160 equality comparison result unused [-Wunused-comparison]
      163 equality comparison result unused [-Wunused-comparison]
      187 expression which evaluates to zero treated as a null pointer constant of type ‘char *’ [-Wnon-literal-null-conversion]
    WordCloud.c 37 using the result of an assignment as a condition without parentheses [-Wparentheses]
      39 using the result of an assignment as a condition without parentheses [-Wparentheses]
      41 using the result of an assignment as a condition without parentheses [-Wparentheses]
      43 using the result of an assignment as a condition without parentheses [-Wparentheses]
      45 using the result of an assignment as a condition without parentheses [-Wparentheses]

  3. What issues does Cppcheck report?

    File Line Warning
    CountedMap.c 44 Uninitialized variable: mapElement
      45 Uninitialized variable: mapElement
      47 Uninitialized variable: mapElement
    PEX5.c 72 Width 5 given in format string (no. 1) is larger than destination buffer ‘charBuffer[5]’, use %4s to prevent overflowing it.
      115 Width 5 given in format string (no. 1) is larger than destination buffer ‘charBuffer[5]’, use %4s to prevent overflowing it.
      163 Width 5 given in format string (no. 1) is larger than destination buffer ‘charBuffer[5]’, use %4s to prevent overflowing it.

  4. What issues does Infer report?

    File Line Warning
    CountedMap.c 47 The value read from mapElement was never initialized.
      67 pointer countedMap->hashTable last assigned on line 63 could be null and is dereferenced at line 67, column 3.
      62 pointer countedMap last assigned on line 59 could be null and is dereferenced at line 62, column 2.
      180 memory dynamically allocated to **outArgWordArray[currIndex] by call to malloc() at line 169, column 22 is not reachable after line 180, column 4.
      179 pointer *outArgIntArray last assigned on line 168 could be null and is dereferenced at line 179, column 4.

  5. Which of the prior warnings and issues appear to be faults (i.e., implementation mistakes)? Which appear to be spurious?