Home
>
Posts
>
I've sent a PVS-Studio text log to the …

Sergey Vasiliev
Articles: 96

I've sent a PVS-Studio text log to the project authors! Did I really help?

Quite often, people who have just started using our analyzer, do the following: they check a well-known project, save the results of the analysis in a text file and send it to the developers thinking that they did a good job. After all, they help to find bugs! I want to tell, why you shouldn't do that.

Since the creation of PVS-Studio, we have tried hard to make it as functional and user-friendly as possible. One of the key things when working with the analyzer is handling the analysis results. Quite often, the way the analysis results are interpreted, influences the overall impression and the efficiency of the use.

So, what's the problem?

At times people don't understand how to correctly use the analyzer results and sometimes - the analyzer itself. Obviously, that's our fault. However, we are trying to make the interface as intuitive as possible, by adding utilities for handling the analysis results to the distribution kit and implementing features to enhance the analyzer report usability. We also provide detailed documentation for all our features, but does anyone really read it?

The problem is in the interpretation of the results. At this point, a log file is provided as an xml-file; some developers try working with it manually. This is a wrong approach; .plog-files are not intended for manual processing! The log file, obtained in the result of the analyzer work, is a collection of information that can be processed in various of ways, by adjusting the analysis results in the most convenient way. On condition that the developer uses necessary utilities. Everything is ready to use - you should just start!

The truth is out there (c)

What features can improve the usability of the log?

  • Disabling diagnostic rules. A number of diagnostic rules may be irrelevant for your project. The best practice is to disable these rules - this allows you to ignore those warnings that are uninteresting for you;
  • Excluding directories from the analysis. You can specify a certain directory, whose file analysis you are not interested in. It would be useful to exclude from the analysis, for example, third-party source code;
  • False positive markup. Using this mechanism, you can mark up false positives of the analyzer; they will not appear in the log and won't hamper its viewing;
  • Sorting the warnings by the severity level. Will allow differentiating the most and least critical errors and thus simplifying the prioritization in the warnings handling.
  • Filtering messages. There are a lot of possible options of filtering: by the error code, by the project name, by the severity level, etc. This will allow filtering the warnings to work with them more comfortably;
  • Conversion to other formats. For example, you can convert the log into an html-file that can be later used for e-mail notification, for example.

Conclusion

Don't try to view a raw log or "reinvent the wheel" for handling the analysis results - most likely, everything you need is already implemented, you should just use them. The documentation gives information about the tools and means for effective using of the analyzer. If there are any questions after reading the documentation - feel free to contact us, we'll be glad to help: support@viva64.com.

Oh, and the most important! Do not send anyone a text log of the PVS-Studio report! You will do more harm than good for the project authors (they won't spend time, sorting out the garbage, anyway). For us it won't be great as well - some may think that PVS-Studio works like a lint-utility from the 80-ies.