How does static analysis differ from compiler warnings?

On the forums, you can sometimes see people who believe that compiler warnings are more than enough to control the main types of errors in the program code. I want to show that it is not.

Specialized static analysis tools and standard warning tools in compilers are aimed at improving the quality of the source code and minimizing potential, hard-to-debug, errors. Either way, compiler messages are issued based on static analysis of the source code at compile time, but the use of this or that method to diagnose potential errors has many differences in both the quality of warnings and the possibilities of use.
')

Compiler analysis

The primary task of the compiler is to get the binary code from the compiled source files. Compilation speed is one of its important characteristics, so not much time is allotted for static analysis of the source code in order to conduct in-depth analysis or operate with a large number of diagnostic rules. Therefore, compilers report only the most common problem constructs in code.

As products of different companies, many compilers can vary greatly in the ability to issue messages to suspicious areas of the source code, so the use of different compilers can also improve the quality of programs. But it is often not possible to compile one program with different compilers, even for a single operating system. Some compilers may provide their own language extensions that are not supported by other compilers, the use of which worsens the portability of the source code. Also, the use of platform-dependent constructions will make it difficult for a program to be checked by another compiler, if it exists only for another operating system.

Third-party analyzers

The situation is different when using specialized static analysis tools. Being developed in one direction, such tools are more flexible and developed in the field of source code analysis of programs. Unlike compilers, static analyzers provide more diagnostic rules, many of which diagnose very unusual and not very common errors.

Using the example of Visual C ++ Compiler and PVS-Studio

The Visual C ++ compiler has C4265 diagnostics, which issue warnings to class declarations without a virtual destructor. This is a very useful diagnosis, but it gives warnings to all classes that do not have a virtual destructor, so it is turned off by default.

A similar diagnosis of the V599 is also found in the PVS-Studio static analyzer. Being a specialized tool in this area, the analyzer has a more intelligent algorithm that issues a warning only if there is at least one virtual function in the basic constructor and an object of this class is destroyed using the delete operator.

Another example is using the memset function. Consider the following sample code.

void Foo() { char password[MAX_PASSWORD_LEN]; InputPassword(password); ProcessPassword(password); memset(password, 0, sizeof(password)); } 

Here it is supposed to clear the buffer containing the password. This code is completely correct from the point of view of the compiler, but a call to the memset function will be deleted by the compiler without warning if you start it with the "/ O2" key. The PVS-Studio analyzer finds such a place using the V597 diagnostics.

The correct code is as follows:

 void Foo() { char password[MAX_PASSWORD_LEN]; InputPassword(password); ProcessPassword(password); RtlSecureZeroMemory(password, sizeof(password)); } 

To clear private data buffers, you need to use the special function RtlSecureZeroMemory .

Conclusion

In conclusion, we note the main points about the source code analysis tools:

• Code analysis is not the main task of the compiler.
• Using different compilers for analysis is difficult, although desirable.
• Compilers cover a small list of common errors.
• Static analyzers specialize only in analysis.
• Static analyzers have an extensive database of diagnostic rules.
• The ideology of some diagnostics does not exclude false positives.
• Different analyzers can be used, regardless of the compiler used.

Using various static analysis tools that differ in the analysis methodology will certainly improve the quality of your program code.