PVS-Studio Declares Love for Linux

This is a note about love. About the love of the PVS-Studio static code analyzer for the wonderful open Linux operating system. This love is young, touching and vulnerable. This love must be helped to strengthen. You will help if you sign up for volunteers in advance to test the beta version of PVS-Studio for Linux.

My colleagues and I for a very long time refused to discuss the topic of developing PVS-Studio for the Linux operating system and the UNIX world as a whole. It's not about some personal addictions or technical difficulties. Everything is simpler - this is a cold, pragmatic approach to product development.

We are a small company that exists solely through the sale of the PVS-Studio software product. We do not receive grants or any other support from the state or large companies - all this imposes a great responsibility for choosing the direction of development.

Now we have accumulated new strength, have gathered our courage and are starting a new topic for us in mastering Linux. Yes, yes, it happened. We decided to start work in this direction. I hope we can do better with this than with CppCat .

PVS-Studio for Windows

First, briefly remind you what PVS-Studio is now, and what it can do at the moment. If you have already read our articles, you can skip this section.

PVS-Studio is a tool for detecting errors in the source code of programs written in C, C ++ and C #. Until now, the analyzer has been aimed at developers using the Visual Studio environment. Supported languages ​​and dialects:

• Visual Studio 2015: C, C ++, C ++ / CLI, C ++ / CX (WinRT), C #
• Visual Studio 2013: C, C ++, C ++ / CLI, C ++ / CX (WinRT), C #
• Visual Studio 2012: C, C ++, C ++ / CLI, C ++ / CX (WinRT), C #
• Visual Studio 2010: C, C ++, C ++ / CLI, C #
• MinGW (partially): C, C ++

The main features of PVS-Studio:

• Automatic analysis of files after recompiling them in Visual Studio.
• Saving and loading analysis results: you can check the code at night, save the results, and download them in the morning and watch.
• Run from the command line to check the whole solution: allows you to integrate PVS-Studio into nightly builds so that everyone has a fresh log in the morning.
• Mark as False Alarm - markup in the code so as not to swear by specific diagnostics in a specific fragment of the file.
• Mass Suppression - suppress all old messages so that the analyzer generates 0 responses. You can always return to them later. Convenient implementation. Errors only in the new code.
• Use relative paths in report files to be able to transfer the report to another machine.
• CLMonitoring - checking projects that do not have Visual Studio files (.sln / .vcxproj); if CLMonitoring functionality is not enough for you, then you can integrate PVS-Studio into any Makefile-based build system manually.
• Good scalability: the analyzer can load all processor cores. Additionally, it can be used in conjunction with IncrediBuild.

You can learn more about the analyzer and download it on the PVS-Studio product page . Finally, I will give a summary table of the main diagnostic capabilities of PVS-Studio. Not all diagnostics are included in the table, since some of them are difficult to classify. This does not hurt to make an overall impression, and in detail with the available diagnostics can be found here . Table 1 - PVS-Studio features. Click on the picture to enlarge it.

PVS-Studio for Linux

Now let's talk about why many people started reading this article: Linux support.



This task is not as simple as it might seem at first glance. Compiling the executable module under Linux and checking something with it is a simple task. We have dealt with it for a long time. A year ago, we wrote an article about an experiment about checking Vim. However, this is only a small part of the total volume of work. Programmers forget that building an executable module and creating a software product is far from the same thing.

We plan to support GCC and Clang. We started with GCC, and we'll come back to Clang later. I’ll tell you about the tasks that now face us.

1. More complete support for GCC and Clang

Sometimes it seems to me that compiler developers are bored, and they come up with various ways to make their lives more difficult, and at the same time, developers who implement code highlighting, static analysis, and so on. In another way, I can’t explain why, for example, I needed to introduce Conditionals with Omitted Operands . Of course, it's cool that you can reduce the ternary operator to: z = x ?: y ;. In my opinion, without this, you can completely do without and live a happy life.

Many people wonder why you need to bother with various documented and undocumented compiler extensions. It seems to be sufficient to analyze C ++ that complies with the standard and not pay attention to extensions, since they are used extremely rarely. Unfortunately, this is not the case, and extensions have to devote a lot of time.

It doesn’t matter if non-standard entities are often found in the program. In any serious program, there will be header files containing some of the extensions. As a result, this confuses the parser in the analyzer, and it cannot fully process many * .cpp files, which include this ill-fated * .h file. Of course, PVS-Studio analyzer has built-in mechanisms that try to compensate for parsing errors and continue the analysis. Unfortunately, this mechanism does not always help. As a result, strange false positives may occur, or vice versa, a fragment of code will be excluded from the analysis (until the end of the function or class, or even the entire file).

Moreover, they like to use all sorts of “tricky” things in system header files. So in practice, running into some kind of extension is very easy.

If someone is interested in what is still being discussed, I can suggest a look, for example, at:

• Gcc. Extensions to the C Language Family
• Gcc. Extensions to the C ++ Language

And these are only documented extensions. From experience with Visual C ++, we still expect the presence of tricks in the form of undocumented extensions.

Since we use our own parser (development of the now forgotten and abandoned OpenC ++ library), we must support various extensions.

However, we would use some other parser, this would not help us much. For example, if we rewrite the analyzer, taking Clang as the basis, we still have to fight independently with the GCC, Visual C ++ extensions.

2. The new regression test system in Linux

When developing PVS-Studio, we use seven testing methods:

1. Static code analysis on developer machines. All developers have PVS-Studio installed. New or changed code is immediately checked using the incremental analysis mechanism. Checked C ++ and C # code.
2. Static code analysis during nightly builds. If the warning was not noticed, then it will be revealed at the stage of nightly assembly on the server. PVS-Studio checks C # and C ++ code. In addition, we additionally use Clang to test C ++ code. At one time, Cx code also additionally used FxCop. During the year, he never found anything useful, and we refused to use it. But Clang found a couple of times errors that PVS-Studio did not notice, and we considered it rational to continue using it.
3. Unit tests of the level of classes, methods, functions. Not a very developed system, since many points are difficult to test because of the need to prepare a large amount of input data for the test. We rely more on high-level tests.
4. Functional tests of the level of specially prepared and marked files with errors.
5. Functional tests confirming that we correctly parse system header files. This is important, since if non-standard extensions are used in the system file, this spoils the verification of many projects at once.
6. Regression tests of the level of individual third-party projects and solutions (projects and solutions) are the most important and useful type of testing for us. To implement it, we regularly check 105 open source projects in C ++ and 49 in C #. Comparing the old and new results of the analysis, we control that we did not break something and hone new diagnostic messages.
7. Functional tests of the user interface. This refers to plug-in testing, which integrates into Visual Studio. We verify that pressing various buttons and menu items leads to the desired results.

In terms of Linux support, we need to first expand the N5 and N6 item. Point N5 overlaps with the previous section, “More Complete Support for GCC and Clang.” Making tests to check system header files is not difficult, but time-consuming to expand the parser. However, we already talked about this, and point N6 is much more interesting.

In fact, this is the largest and most complex test system we use. Here's what this program looks like in the process of work: There is no point in describing this tool in the article, since it is intended exclusively for internal use. I can only say that it makes it very convenient for developers to track the results of their edits in the analyzer core and the addition of new diagnostics.





So, now we have to create an analogue of such a system for Linux. Since this is a very important part of the analyzer development process, we must approach this task with all seriousness. We will also need to do a lot of work to select open projects, on which the analyzer will be tested. On the one hand, these projects should not be too large so as not to make the inspection time too long. On the other hand, they should be “saturated”: in different projects different approaches to programming should be used. That is, it is desirable that goto operators are actively used somewhere, somewhere actively using templates, somewhere actively working with Unicode and so on. This makes analyzer testing more comprehensive. To collect such a collection of source codes is a very difficult task, requiring time to study a large number of open source projects.

3. Monitoring compilers

PVS-Studio for Windows includes the GUI utility Standalone.exe. Using it, you can conveniently work with reports (* .plog files) if the Visual Studio development environment is not installed: But this is not the main thing. More importantly, with the help of this utility you can check the project assembled by any exotic or self-constructed assembly system. However, this is not intended specifically for exotic situations. Even if you have a classic makefile, it is easier to perform analysis using Standalone than to understand the PVS-Studio documentation in order to register the analyzer call in maklefile.





Standalone allows you to track the starts of the Visual C ++, GCC (MinGW), Clang compilers and collect all the necessary information for verification. It looks like this: you tell the program to "start surveillance", and then perform the usual assembly of the project. Next, you say “done” to the program. The analysis of all those files that have just been compiled begins.

By the way, all this does not have to be done manually. You can use the console utility CLMonitor.exe to verify the project on the server. It also collects information about running compilers and performs project validation.

When implementing the Linux version, we immediately decided that we needed to support tracking of compiler launches. This will help programmers get acquainted with the PVS-Studio analyzer faster and easier. The fact is that using this utility, the project will be able to verify any member of the team, without distracting people who support makefiles and the build system in general. In large projects, not everyone knows how their application is actually assembled. Moreover, not everyone will find the time and desire to figure out how and where to register the PVS-Studio call. All this can still be complicated by the presence of an auto-generated makefile. It is clear that everything can be understood, but this is a significant barrier to the first verification of the project and the satisfaction of research curiosity.

So you got acquainted with another subtask of creating a Linux version. We are working on developing a system for monitoring compiler launches and collecting all the necessary information for verification.

4. Finalization of documentation

When writing documentation, we always encounter opposing desires. On the one hand, we have always tried to keep the product simple and clear, and to work with it we did not need to get acquainted with a lot of leadership. On the other hand, static analysis is a rather complicated tool, and all the subtleties of working with it should be reflected in the manual. This is especially true for the description of diagnostic messages : there are many of them, and it is necessary that each of them be described in detail and accompanied by code examples.

As a result, we have a lot of work to correct and supplement the documentation with sections on working in Linux. Plus, we need to figure out how to realize the ability for users to quickly receive information on a particular diagnostic. In Visual Studio there is no problem - just click on the error code in the list of warnings and the corresponding page will open.

How and what to offer in the Linux environment - it is necessary to think. Of course, there is always a PDF file (350 pages) or online documentation on the site, but this can not be called a convenient way to access the description of diagnostics.

5. Website revision

The site, of course, will also require refinement. This is not a programming task, but it is necessary to deal with it, so I decided to mention the site for educational purposes. Many programmers only think about the code and forget that many other colleagues are involved in the release of the product, solving a large number of tasks hidden from them.

6. Other: testing, distribution, support organization

Naturally, do not forget about testing. Although multilevel tests will reveal most of the problems, some completely unexpected errors or shortcomings will most likely manifest themselves. Now it’s even impossible to assume that it will be, but we have no illusions about the ideality of the world. Under Windows, we were faced with a variety of situations where it seems we are not to blame, but something does not work correctly. I spoke about some of these unpleasant surprises in an interview about 2 years ago (look for the phrase “Unfortunately, all the beauty and reliability of the internal code sometimes falls apart due to the effects of a hostile environment”). I am sure that similar surprises await us on Linux.

The results of our work must be wrapped in a distribution that can be easily downloaded and used. Saying this is much easier than doing it. I think it will take more than one iteration to make it convenient and take into account various subtleties.

And the last: we must organize support for a new direction. Our users value us for their quality and prompt support. With the release of the Linux version, the number of requests will increase, especially at the beginning, when not everything will work, and we should be prepared for this.

7. Future plans

Above, I have described far from everything that we will need to spend time on adapting PVS-Studio to Linux. There are many smaller tasks that you won’t remember right away, and it’s not interesting to write about them. For example, I need to write this and many other articles that will tell people that PVS-Studio for Linux has appeared.

There are also big tasks that we will deal with later. For example, as I said, at first we focused on GCC, and only then we plan to work out with Clang. I don’t even know if the first release version of PVS-Studio for Linux will support Clang or not.

Here are some more of the big challenges that await us:

• Integration with Qt Creator.
• Integration with ... (time will tell).
• Improvement and improvement of diagnostics. For example, inside PVS-Studio there are tables with information about typical functions, such as malloc, memset, std :: swap. This information allows you to identify many errors in the incorrect use of functions. It is worth expanding these tables with many of the features described in POSIX.

In progress

We look forward to introducing something to the world. I hope I am interested in you, and many Linux developers would like to try to test their projects. If you have the desire and time, I invite you to join the group of beta testers in advance.

So, if you want to help us verify the operation of PVS-Studio for Linux, please write to us. To make it easier to process letters, please indicate the line “PVS-Studio for Linux, Beta” in the subject line. Send letters to support@viva64.com . Please write letters from corporate mailboxes and introduce yourself briefly. We will be grateful to everyone who responds, but first of all we will pay attention to those people who could potentially become our customers over time.

I also ask in the letter to give answers to the following questions:

• Under which operating system do you plan to run the analyzer?
• What development environment are you using?
• What compiler is used to build the project?
• What build system are you using?

When a version appears that you can try, we will write all the responding letters.

Thank you all in advance. We will occasionally mention in articles how the development of PVS-Studio for Linux is progressing. I wish everyone to run the debugger less often!