CppDepend is a tool that simplifies managing a complex C\C++ code base. Architects and developers can analyze code structure, specify design rules, do effective code reviews and master evolution by comparing different versions of the code.
CppDepend focus more on design analysis to understand the structure of existing code, and many times we ask us if CppDepend can detect implementation problems, like variables not initialized, 64 bits and parallel issues.
For that there are other tools that complements CppDepend to detect this kind of issues and we recommend PVS-Studio.
PVS-Studio is a static code analyzer intended for developers of modern resource-intensive C and C++ applications. By modern applications we understand 64-bit and/or parallel applications. Development of such programs involves some difficulties different from the problems you face when developing conventional programs. For besides usual errors known to everybody like uninitialized pointers, which are detected by any compiler, there are new types of problems.
We speak about the errors in programs which occur when porting 32-bit applications on 64-bit platforms or paralleling the code to provide support of multi-processor or multi-core mode. It is rather difficult to develop such applications because of lack of tools which could simplify creation of 64-bit and parallel programs. PVS-Studio analyzer is quite a tool for this purpose!
Though PVS-Studio code analyzer user interface is rather simple, still, to use the tool most efficiently, you should understand the principles and technology of static code analysis. After reading this article and examining the examples described in it, you will be able to use PVS-Studio in your everyday work.
Purpose, abilities and system requirements of PVS-Studio.
The static code analyzer PVS-Studio is intended for developers of modern resource-intensive C and C++ applications. At present, PVS-Studio includes two units:
• Viva64 is a subsystem of diagnosing errors characteristic of 64-bit systems;
• VivaMP is a subsystem of diagnosing errors in parallel programs built on OpenMP technology.
With the help of these two units PVS-Studio allows you to detect in the source code of C and C++ programs the following types of defects:
• errors of migration of 32-bit applications on 64-bit systems;
• errors occurring when developing new 64-bit applications;
• non-optimal use of memory in 64-bit programs due to alignment peculiarities;
• errors in parallel programs relating to insufficient knowledge of OpenMP directives’ syntax;
• errors in parallel programs relating to insufficient knowledge of the principles of paralleling code using OpenMP technology;
• errors of incorrect memory operation in parallel code (unprotected main memory access, absence of synchronization, incorrect mode of access to variables etc).
PVS-Studio analyzer is intended for working on Windows-platform. It integrates into Microsoft Visual Studio 2005/2008/2010 development environment. The system requirements to the analyzer coincide with the requirements to Microsoft Visual Studio:
• Operation System: Windows 2000/XP/2003/Vista/2008 x86 or x64. Attention: to analyze 64-bit applications it is not necessary to have a 64-bit operation system.
• Development environment: Microsoft Visual Studio 2005/2008/2010 (Standard Edition, Professional Edition, Team Systems). To analyze 64-bit applications you must have a component of Visual Studio “X64 Compilers and Tools” installed. It is included into all the listed versions of Visual Studio and can be installed through Visual Studio Setup. Pay attention that PVS-Studio cannot operate Visual C++ Express Edition for this system does not support extension units.
• Hardware: PVS-Studio operates on systems with no less than 1 Gb of main memory (it is recommended that you have 2 Gb and more); the analyzer can work at several cores (the more cores, the faster code analysis).
Getting acquainted with PVS-Studio
After installing the examples PortSample and ParallelSample you can start examining PVS-Studio. Open PortSample project in Microsoft Visual Studio.
Figure 1 – Selection of PortSample demo-project
You should begin working with PVS-Studio with one of our demo-projects due to some reasons:
• firstly, they cover all the code defects diagnosed by PVS-Studio;
• secondly, you can watch behavior of an application with an error in a real example;
• thirdly, PVS-Studio demo-version shows location only of some of the defects and errors in the code (although it detects them all). But for PortSample and ParallelSample we have made an exception – for them all the defects are shown.
So, open PortSample project, select 64-bit configuration x64 to check presence of defects in 64-bit code, with the help of PVS-Studio command bar select analysis of 64-bit problems – Viva64 unit “64-bit issues (Viva64)” and launch analysis of the whole solution by the command “Check Solution”. All this is shown on Figure 2.
Figure 2 – Check of PortSample solution on presence of 64-bit problems
x64 configuration is chosen deliberately. You can check only the 64-bit configuration on 64-bit code problems. The point is that the project’s settings in the 64-bit configuration are different from those of the 32-bit one. So you cannot perform check of 64-bit code in the 32-bit configuration.
After launching analysis, you will see a progress indicator with Pause (pause analysis) and Stop (stop analysis) buttons on the screen. Potentially unsafe constructions detected during analysis will be printed in the window of detected defects (Figure 3).
Figure 3 – Analysis of the project – problems detected in the code are printed in the window at once
The term “potentially unsafe construction” means that the analyzer considered some particular code line a defect. But only the programmer who knows the application can determine if this line is really a defect of the application or not. This principle of working with code analyzers must be understood correctly.
Generally, no tool can replace a programmer completely when solving the task of correcting errors in programs. Only a programmer can do it relying on his knowledge. But a tool can and must help the programmer in this task. That’s why a code analyzer’s task is to reduce the number of places in the code which the programmer must look through and investigate.
But let’s return to PVS-Studio analyzer. Analysis of the whole code is complete and now you can start looking through the messages. By the way, if you have a multi-core processor analysis will be performed faster for all the cores will be used.
Correction of errors
After getting a list of diagnostic warnings from the code analyzer, you can study it. Let’s consider the first
error:
V101: Implicit assignment type conversion to memsize type. v1xx.cpp 34
Here is its code:
size_t bufferSize = imageWidth * imageHeght *
bytePerPixel * maxFrameCountInBuffer;
The problem here is that the resulting size of the buffer (bufferSize variable) has the right size size_t but the variables participating in the expression (imageWidth, imageHeight, bytePerPixel and maxFrameCountInBuffer) have int type. The result of multiplication of these variables has also int type. It is not crucial for values less than 2 Gb for type conversion takes place. But if you get a result more than 2 Gb it will be cut to 2 Gb despite that bufferSize variable has a right type. To correct this error you should change the type of the variables participating in the expression. You can do this in a preciding code section. Instead of:
unsigned imageWidth = 1000;
unsigned imageHeght = 1000;
unsigned bytePerPixel = 3;
unsigned maxFrameCountInBuffer;
let’s write:
size_t imageWidth = 1000;
size_t imageHeght = 1000;
size_t bytePerPixel = 3;
size_t maxFrameCountInBuffer;
You can learn about this correction from the Help system. After pressing Alt+H (with mouse or F4 button) when studying a new error, the online help page will open with the description of the error:
Figure 4 – Detailed description of the error and the ways to correct it are given in online help
After correcting the used data types let’s relaunch analysis. You will see that the number of diagnostic warnings is less in one. It means that the problem is corrected. In the same way you should deal with all the diagnostic warnings and correct those places in the code where there are possible problems.
Working with the list of diagnostic warnings
Of course, in large real projects there will be not some tens of diagnostic warnings, but hundreds or even thousands of them. And looking through all of them is not a simple task. To simplify it PVS-Studio has several mechanisms. The first is filtration of warnings by the code of an error. The second is filtration by the content of the text of a diagnostic warning. The third is filtration by the paths to files. Let’s consider the examples of using filtration systems.
Suppose you be sure that diagnostic messages with V112 code (using magic numbers) are not relevant to your application. In this case you may turn off showing of these diagnostic warnings with the help of the code analyzer’s settings:
Figure 5 – Turning off some diagnostic warnings by the code
After that all the warnings with V112 code will disappear from the list of warnings. And you do not need to relaunch analysis for this. If you turn on these warnings they will appear in the list again without relaunching analysis.
Now let’s consider another variant of filtration on the basis of the text of diagnostic warnings. Let’s get back to PortSample example. One of the errors in this example is access to the array “array” using an index of int type:
V108: Incorrect index type for “array”. Use memsize type instead. v1xx.cpp 183
Here is the code:
volatile int index = 0;
for (size_t i = 0; i != n; ++i) {
array[index++] = 1; // error
if (array[i] != 1)
throw CString(“x64 portability issues”);
}
Of course, you may just change the type of index variable from unsigned to size_t and the problem will disappear. But if there are a lot of code sections with access to array variable and you are sure that there are not more than 2 billions of items in array, you may “ask” the code analyzer not to show the warnings whose text contains the word “array”. You can do this with the help of the settings on MessageSupression page:
Figure 6 – Turning off some diagnostic warnings by the text
After that all the diagnostic warnings whose text contains the word “array” will disappear from the list without relaunching the code analyzer. You can get them back by simply removing the word “array” from the filter.
The last mechanism of reducing the number of diagnostic warnings is “Don’t Check Files” setting.
You may specify file masks on the tab “Don’t Check Files” to exclude some files from analysis. The analyzer will not check those files that meet the mask’s conditions.
Figure 7 – Setting filtration of messages by files’ names
Using this method, you may, for instance, exclude autogenerated files from analysis. Besides, you may define the files to be excluded from analysis by the name of the folder they are situated in.
A mask is defined with the help of wild card match types like in MS-DOS. The following wild cards can be used:
• ? – any character;
• – any number of any characters;
The case of characters does not matter.
If a mask is specified without a full path (i.e. without the characters “:” and “\”), the check is performed ONLY by the file name. For instance, the mask “V*.CPP” covers the files c:\test\V1111.cpp and d:\project\V1111.cpp. But if you define the mask as c:\*.cpp, the file d:\project\V1111.cpp will not fall under it.
Here are some examples:
*ex.c – all the files whose names end with “ex” and which have the extension “c” will be excluded from analysis.
c:\Libs\*.cpp – all the files with the extension “cpp” in the folders c:\Libs\XX, c:\Libs\XX\YY, c:\Libs\ZZ, etc. will be excluded.
If you change a mask, you will need to relaunch the analyzer.
In PVS-Studio, there is a possibility called “Mark as False Alarm”. Due to it, it is possible to mark those lines in the source code, in which false alarm of the code analyzer occurs. After the marking, the analyzer will not produce diagnostic messages for such code any more. This allows to use the analyzer constantly with more convenience in the process of software development for verifying new code.
Thus, in the following example, the output of the diagnostic message with code V104 is disabled:
size_t n = 100;
for (unsigned i = 0;
i < n; //-V104
i++)
{
// …
}
This feature is described thoroughly and in detail in the article "PVS-Studio: use of "Mark as False Alarm" function".
There are also many other means to handle diagnostic warnings to be shown by setting the code analyzer but they lay beyond consideration in this document. We recommend that you refer to the documentation on the code analyzer's settings.
Should all the potential errors detected by the analyzer be corrected?
Having looked through all the warnings shown by the code analyzer you will find both real errors in programs and constructions that are not errors. The point is that the analyzer cannot detect all the errors in programs 100% accurately without the so called "false responses". Only the programmer who knows and understands the program can determine if there is an error in a particular place. The code analyzer can only significantly reduce the number of sections which must be looked through by the developer.
Thus, of course, there is no sense in trying to correct all the potential problems detected by the code analyzer.
But you should try to correct as many code sections as you can. It is especially relevant when the static analyzer is used not once just to verify an application when, for example, porting it on a 64-bit system, but regularly with the purpose to detect new errors and insufficient constructions. In this case correction of sections which are actually not errors, and also setting of the analyzer to suppress some types of errors will allow you to significantly save on time when using the analyzer next time.
Filed under: Uncategorized
