OOO "Program Verification Systems"
Use PVS-Studio to check 64-bit and parallel applications
05.02.2010
/Wp64 switch and template processing error
While maintaining the analyzer Viva64 (included into PVS-Studio) we often comment upon the switch /Wp64 of Microsoft Visual C++.»
03.02.2010
Parallel notes N1 - OpenMP technology
In the next few posts we will tell you about using multi-core processors in practice.»
29.01.2010
64-bit technologies - one more trend in the modern software
In the blogs and forums, there is much discussion of multi-core processors as an evident step of computer system development.»
2.02.2010 "Lessons of 64-bit C/C++ software development" are now available on our site.»
1.02.2010 PVS-Studio 3.45 New Version Released!»
21.01.2010 PVS-Studio 3.44 New Version Released!»
10.12.2009
PVS-Studio FAQ
This paper contains some questions and answers about PVS-Studio code analyzer by OOO "Program Verification Systems".»
09.12.2009
VivaCore FAQ
This paper contains some questions and answers about VivaCore C/C++ code analysis library by OOO "Program Verification Systems"»
23.11.2009
PVS-Studio: using the function "Mark as False Alarm"
The article describes and demonstrates by an example the use of PVS-Studio 3.40 new function "Mark as False Alarm". »
The article is a tutorial on operating PVS-Studio code analyzer. You will learn about the basic abilities of PVS-Studio, the principles of working with the tool and also about the peculiarities of analyzing the code of applications of some types.
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.
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:
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:
PVS-Studio analyzer is intended for working on Windows-platform. It integrates into Microsoft Visual Studio 2005/2008 development environment. The system requirements to the analyzer coincide with the requirements to Microsoft Visual Studio:
After getting PVS-Studio installation package you can begin installing the program. Fortunately, this is quite a simple procedure and the installer asks no tricky questions.
During installation, the code analyzer will integrate into Microsoft Visual Studio. In case you have only one version of Microsoft Visual Studio (for example, only 2005 or 2008) installed on your computer the analyzer will integrate only into it. If you have several versions, it will integrate into all of them. It is detected automatically.
Besides, PVS-Studio Help system will integrate into MSDN. PVS-Studio has a very good Help system which contains descriptions of all the diagnostic warnings of the analyzer with examples of code defects and ways to correct them. Besides, it also describes all the settings with the help of which you can achieve better diagnosis in PVS-Studio.
When installation of PVS-Studio is complete you can make sure that it has been installed correctly. For this launch Microsoft Visual Studio and in the start window you will see the logo of PVS-Studio (Figure 3).
Although you can begin working at once, we recommend that you install two additional examples of source codes PortSample and ParallelSample (Figure 4) from PVS-Studio\Issues Examples menu.
With the help of these examples you can get acquainted in practice with the defects which are characteristic of modern software. PortSample contains examples of problems occurring when porting software from 32-bit systems on 64-bit ones. ParallelSample allows you to see in practice what you can expect from parallel programs containing "parallel" errors.
These examples (PortSample and ParallelSample) should be installed because the further description in this article will be based on them.
After installing the examples PortSample and ParallelSample you can start examining PVS-Studio. Open PortSample (vs2008) project in Microsoft Visual Studio 2008 although you can do the same in Microsoft Visual Studio 2005 (Figure 5).
You should begin working with PVS-Studio with one of our demo-projects due to some reasons:
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 6.
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 7).
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.
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 F1 (with mouse or F4 button) when studying a new error, the MSDN window will open with the description of the error:
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.
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:
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:
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 filtration on the basis of the paths to the project's files.
Suppose your project use Boost library. Of course, the analyzer will warn about potential problems in this library as well. But if you are sure that these warnings should not be considered you may simply add the path to the folder with Boost on ExcludeFromAnalysis page:
After that the diagnostic warnings relating to the files in this folder will not be shown. This option requires relaunching the code 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.
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.
Home | About Us | Contact Us | Privacy Policy | Terms of Use
© 2008 - 2010, OOO "Program Verification Systems". 300027, Russia, Tula, P.O. Box 1800. Office: Russia, Tula, Kutuzova 100-73.
