How is static analysis different from compiler warnings?

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

Specialized static analysis tools and standard warning tools in compilers are aimed at improving the quality of source code and minimizing potential, difficult to perceive debugging errors. One way or another, compiler messages are issued on the basis of a static analysis of the source code at compile time, but using one or another method to diagnose potential errors has many differences both in the quality of warnings and in the possibilities of use.

Compiler Analysis

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

As products of different companies, many compilers can differ greatly in their ability to issue messages to suspicious portions of the source code, so using different compilers can also improve the quality of programs. But often there is no way to compile one program with different compilers, even for the same operating system. Some compilers may provide their own language extensions unsupported by other compilers, the use of which impairs portability of the source code. Also, the use of platform-dependent constructs makes it difficult to check the program with another compiler, if it exists only for another operating system.

Third Party Analyzers

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

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

The Visual C ++ compiler has a C4265 diagnostic that issues warnings for declaring a class without a virtual destructor. This is a very useful diagnostic, but it gives warnings to all classes that do not have a virtual destructor, so it is turned off by default.

A similar diagnostics of V599 is also 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 base constructor and the object of this class is destroyed using the delete operator.

Another example involves using the memset function. Consider the following code example.

voidFoo(){
  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 the call to the memset function will be deleted by the compiler without warning if you run it with the key "/ O2". The PVS-Studio analyzer finds a similar place using the V597 diagnostic .

The correct code is as follows:

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

To clear buffers containing private information, you must use the special RtlSecureZeroMemory function .