Abstract Introduction Preparation before usage Description of "Mark as False Alarm" function The principle of constantly using PVS-Studio in the process of project development Implementation explanations Other ways of warning filtration in PVS-Studio analyzer Possible issues Conclusion References Abstract The article describes and demonstrates by an example the use of PVS-Studio 3.40's new function "Mark as False Alarm". This function allows you to mark the PVS-Studio analyzer's diagnostic warnings that are "false alarms" in order to omit their appearance at the next launch of the analyzer. Introduction Besides relevant warnings about errors, any code analyzer always generates a lot of the so called "false alarms". These are the cases when it is absolutely obvious to the programmer that there is no error in the code but it is not so obvious to the analyzer. The reason for that is clear - the programmer has more information about the project, admissible input parameters and ways of using its code. The program that has no intelligence and knowledge (i.e. any code analyzer) cannot be as precise. That is why the analyzer generates many warnings which seem absolutely stupid. All in all, there are two approaches to this situation when the tool produces much "noise" besides relevant warnings (warnings about actual errors). The first approach is to show only those error warnings which refer to 100% recognized errors. In this case, you risk missing some errors whose existence is evaluated with a low probability. I.e. there will be very few false alarms but you may miss real errors. The second approach is to show all the warnings about all the errors which may (not necessarily) be real problems. In this case, there will be a lot of false alarms, yet you will hardly miss actual errors. In any code analyzers (not only in PVS-Studio), it is reasonable to apply the second method. The reason for that is very simple: any tool for detecting programming errors is used whenever it is impossible to find problems without it. Respectively, it is often the only way to find defects lurking in multimegabyte ten year-old code. And if some tool does not generate an error warning considering this error "not convincing enough", this tool is not too worthy. So vast an introduction is an attempt to explain why PVS-Studio analyzer generates rather a lot of warnings about errors which are not errors actually. The code analyzer is a tool that suggests the places in program code that the programmer should look through and determine if there are real errors or not. If the code analyzer generates too many warnings about potential problems, of course the programmer must look through many fragments. But if the analyzer generates few warnings (and only about true errors) the programmer will simply miss the code lines with actual defects. So, we have made out that the analyzer cannot but generate many diagnostic warnings. But how to deal with such a number of warnings? With the help of a new function of PVS-Studio 3.40 "Mark as False Alarm", it is more convenient to work with a large number of warnings. This article describes the mentioned function. Preparation before usage In PVS-Studio 3.40, you can now mark an error warning received from PVS-Studio as a false alarm. You can do it either manually or with a menu command or toolbar. Let us show how to use this function by the demo-example PortSample included into the distribution-kit together with PVS-Studio. First of all you should install PortSample (Figure 1). Figure 1 - Installing PortSample example Then open PortSample (Figure 2). Figure 2 - Opening PortSample example After opening the project launch analysis with "Check Solution" command (Figure 3). Figure 3 - Launching analysis When the analysis is over you will see a list of warnings about the problems detected (Figure 4). Figure 4 - The list of problems detected by PVS-Studio This warning list must be looked through and analyzed. Description of "Mark as False Alarm" function Let us turn to the very first error warning: Code: v1xx.cpp(34): error V101: Implicit assignment type conversion to memsize type. This warning (and this line) refers to the following code: Code: size_t bufferSize = imageWidth * imageHeght * bytePerPixel * maxFrameCountInBuffer; This issue is related to the variables which are defined above and have unsigned type: Code: unsigned imageWidth = 1000; unsigned imageHeght = 1000; unsigned bytePerPixel = 3; unsigned maxFrameCountInBuffer; This is an error and you should use size_t instead of unsigned. But if in your case, this error is not relevant you may "disable" showing this particular class of warnings (V101) in this particular line (34) of this file (v1xx.cpp). To do this, select the error warning in the window Error List and choose the command "Mark Selected Errors as False Alarm" or choose the same command in PVS-Studio menu or on the toolbar (Figure 5). Figure 5 - "Mark Selected Errors as False Alarm" command After that, the comment " //-V101" will be automatically added to the code: Code: size_t bufferSize = imageWidth * imageHeght * //-V101 bytePerPixel * maxFrameCountInBuffer; This comment informs the code analyzer that it should not show the warning about the error in this line next time. You may add the comment manually without using "Mark Selected Errors as False Alarm" command but you must strictly follow the note's format: two slashes, minus (without space), error code. After marking the warning as a false alarm you may choose the command "Refresh Error List to Hide Errors Marked as False Alarm" (Figure 6) to update the list of error warnings and hide the unnecessary warning. The list in the window Error List will be shorter by one warning. Figure 6 - "Refresh Error List to Hide Errors Marked as False Alarm" command You may remove the comment with the command "Remove False Alarm Mark from Selected Errors", selecting the error warning in Error List window first. You may also remove the comment manually. Figure 7 -"Remove False Alarm Mark from Selected Errors" command So, we marked one error as a "false alarm". Before marking, we had had 35 (depending on the settings) warnings in Error List window. Let us relaunch the analysis. We will get 34 warnings. The warning we have marked "false alarm" is missing in the warning list. If you need to see all the warnings in Error List window including the ones marked False Alarm choose the command "Show Errors Marked as False Alarm in Error List" (Figure 8). Figure 8 - "Show Errors Marked as False Alarm in Error List" command You may mark several warnings at once. To do this, select them in the window Error List (Figure 9). Figure 9 - Selecting several warnings to mark in Error List window Actually, you may select all the warnings in the list and mark them. But we do not recommend it. First, it contradicts the very idea of a code analyzer as a tool which just informs the programmer about the fragments to consider. Second, despite thorough testing of our tool, you can never say if no errors will occur when adding the marks into the code. It is not that we are not sure about our tool, but let this "horror story" be to urge users to look through all the warnings and refrain from marking them all as "false alarms" by one click. We will give one more reason for looking through all the errors in the article section devoted to potential issues of the mentioned unreasonable approach. The principle of constantly using PVS-Studio in the process of project development Introduction of "Mark as False Alarm" function into PVS-Studio significantly enhances the potential of introducing the code analyzer into the software development process. Now the analyzer can be conveniently launched not from time to time but every day, for instance. The mechanism of exploiting the analyzer in this way consists of two steps: introduction and constant use. Suppose we have a large program project of several millions of code lines. There are twenty programmers participating in the project all the time. Suppose we need to port this project to a 64-bit system (The procedure of using PVS-Studio parallel code analyzer is absolutely the same, but to make it clearer, let us talk about developing a 64-bit version). We offer that you use our tool in this way. At first, a team of five developers creates the base compiling configuration of the 64-bit version of the product, fixes the basic errors and compiler's warnings. After that, the project is split into parts shared among the developers and PVS-Studio analyzer is launched. For some time (days/weeks/months), depending on the size of the source code, the team either fixes the problems detected (the analyzer's warnings) or mark them False Alarm in the code. As a result, when the work on code migration is over, PVS-Studio will generate no new warnings because all the errors are either corrected or marked as false alarms. After that, the other 15 developers begin working on the project (and its further development). While creating a new code, they can launch the analyzer every day and fix possible errors only in the new code. And they will not see the previous, already treated, warnings of the analyzer. This approach allows you not only port an application to a 64-bit platform, but also make sure that there are no 64-bit problems in the freshly developed code. Naturally, you can use PVS-Studio to search for parallel programming errors in the same way. The first step of analyzing and marking false alarms is performed by a small team of developers. After that, PVS-Studio can be used by the whole team who can consider errors only in the new code they are responsible for. Implementation explanations This section discusses the implementation principles. The users not worried by the question: "Why do you use comments but not the standard #pragma-directives?", may skip this section. Usually, #pragma-directives are used in compilers to suppress some error warnings. Here is a code sample: Code: size_t n = 100; unsigned arraySize = n * sizeof(INT_PTR); The compiler generates the warning: Code: 1>.\V1XX.cpp(84) : warning C4267: 'initializing' : conversion from 'size_t' to 'unsigned int', possible loss of data This warning can be suppressed by the following construct: Code: #pragma warning (disable:4267) More exactly, it is better to arrange the code in the following way to suppress the particular warning: Code: #pragma warning(push) #pragma warning (disable:4267) unsigned arraySize = n * sizeof(INT_PTR); #pragma warning(pop) Nothing prevented us from exploiting the same approach in PVS-Studio but we decided to make it differently. We use comments of a special kind for marking. Suppression of the warning by PVS-Studio for the same code line will look as follows: Code: unsigned arraySize = n * sizeof(INT_PTR); //-V103 The difference does not seem to be great and we could well expand the syntax of one-line #pragma-directives to avoid writing push/pop for every construct. But this variant has one crucial disadvantage. The point is that PVS-Studio can inform about problems in the middle of multi-line expressions as, for example, here: Code: size_t n = 100; for (unsigned i = 0; i < n; // the analyzer will inform about the problem here i++) { // ... } To suppress this warning by using comments you should simply write: Code: size_t n = 100; for (unsigned i = 0; i < n; //-V104 i++) { // ... } But if you added a #pragma-directive into this line, the code would be less transparent. So, using comments instead of #pragma-directives for marking files is much more convenient. Another question on implementation of the marking mechanism that may arise is: "Why touch the code at all? Cannot you store the information about false alarms in some other place separately from the code?" In theory, we can make a separate base to store information in a format like this: error code, file name, line number. But this method is very bad. For if you add some lines in the beginning of the marked file, all the marked warnings will move and the base will become irrelevant. But when marks are stored in the source code, any modification of the code will not cause losing the information about the line with an error. Other ways of warning filtration in PVS-Studio analyzer Besides the new method of warning filtration described in this article, we will remind you of three other ones implemented in the analyzer initially. First, you may disable diagnosis of particular errors by their code. It is done using the tab "Settings: Detectable Errors". On the tab of the errors being detected, you may define the numbers of errors that should not be shown in the analysis report. Sometimes it is reasonable to hide the errors with particular codes from the report. For example, if you are sure that the errors related to explicit type conversion (the codes V201, V202, V203) are not relevant to you, you may hide them. Second, you may disable analysis of some project's parts (more exactly, some project's folders). This is the tab "Settings: Exclude From Analysis". On this tab, you may add information about the libraries whose files' inclusions (through #include directive) should not be analyzed. You may need this to reduce the number of unnecessary diagnostic warnings. For example, your project uses Boost library. And although the analyzer may generate warnings on some code fragments of this library, you consider it rather safe and well-written. That is why you consider it unreasonable to see the diagnostic warnings related to this library's code. In this case you may disable analysis of the files from this library by defining its path on the settings page. Third, you may suppress particular warnings by the text. On the tab "Settings: Message Suppression", you may set filtration of the errors by the text they contain instead of their code. If necessary, you may hide in the report the warnings about the errors detected which contain particular words or phrases. For example, if the project has errors containing the names of the functions printf and scanf and you consider that there can be no errors related to them, simply add these two words with the editor of suppressed warnings. Possible issues When using "Mark as False Alarm" function, some issues may occur. Although they are not related directly to PVS-Studio analyzer, it is desirable that you know about them. Sometimes the analyzer "misses" the line containing an error. For example, the analyzer says that there is an error in line 57 but line 57 is actually empty. And the source code that does contain the error is just above, for example, in line 56. The point is that the analyzer uses the Visual C++ preprocessor. And the preprocessor has some errors. For example, Visual Sutdio 2005 (without Service Pack 1) has a problem with multi-line macros (#define). Fortunately, Visual Studio 2005 Service Pack 1 and Visual Studio 2008 do not suffer from it. To learn more about it, see our blog (PVS-Studio refers to error "Some diagnostic messages may contain incorrect line number for file ...") Another problem of the preprocessor is related to multi-line #pragma-directives of a particular type which also cause line numeration confusion. Unfortunately, this error has not been corrected in any version of Visual Sutdio. See our blog for details (PVS-Studio prints the error "Some diagnostic messages may contain incorrect line number for file ..." (continuation)). So, what consequences can line numeration confusion in the PVS-Studio warnings have? For example, the marks added automatically will be in the wrong places. And the analyzer will show the same error warnings once again because it fails to find the marks. To solve this problem you should mark the warnings with the wrong line numbers manually. But we want to calm the reader now for these problems are quite rare. And when line-numbers of the file are confused, PVS-Studio always warns about it by the message "Some diagnostic messages may contain incorrect line number for file ...". If you do not see this message there is no problem. I repeat: it occurs very rarely for very specific projects. Another possible problem is related not to PVS-Studio but to the very procedure of working with the files of the source code. We tested the file marking mechanism very thoroughly and were very attentive when testing the code. However, one cannot insure oneself completely against the failures of file processing (especially mass processing). So, we speak not about the problems of PVS-Studio. Theoretically, when marking the files, one of them may be opened in the external editor and modified there. It is impossible to predict the result of such an operation over the file. Although it is not the fault of PVS-Studio, the user might think so. That is why we recommend that you either have a copy of the source codes or just use version control systems. We are sure that the user does have and use such a system. But it is never bad to warn once again. Conclusion PVS-Studio analyzer has become much more convenient with the new function "Mark as False Alarm". We hope that now you can exploit it during the whole development process. And it means that there will be much less 64-bit and parallel errors in your programs. References Evgeniy Ryzhkov. Getting acquainted with PVS-Studio code analyzer. http://www.viva64.com/art-4-2-969771740.html Evgeniy Ryzhkov. PVS-Studio Tutorial. http://www.viva64.com/art-4-2-747004748.html
