PVS-Studio confesses love to 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 needs help to be strengthened. You can help if you sign up in volunteers beforehand for testing the beta version of PVS-Studio for Linux.

For a very long time, my colleagues and I refused to discuss the topic of developing PVS-Studio for the Linux and UNIX operating systems of the world as a whole. This is not about some personal predilections or technical difficulties. Everything is easier - it 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 great responsibility for the choice of the direction of development.

Now we have accumulated new strengths, have gathered our courage and are starting a new topic for us to master Linux. Yes, yes, it happened. We decided to start work in this direction. Hopefully with this we ’ll get better than with CppCat .
')

PVS-Studio for Windows

At the beginning I’ll 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 # languages. The analyzer has so far been targeted 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 ++

Main features of PVS-Studio:

• Automatic analysis of files after their recompilation in Visual Studio.
• Saving and loading analysis results: you can check the code at night, save the results, and load them in the morning and watch them.
• Running from the command line to check the entire 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 specific diagnostics in a specific file fragment.
• Mass Suppression - suppress all old messages so that the analyzer generates 0 operations. You can always return to them later. Convenient implementation. Errors only in the new code.
• Using relative paths in report files to enable report transfer to another machine.
• CLMonitoring - checking for projects that do not have Visual Studio files (.sln / .vcxproj); if CLMonitoring's 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 the processor cores. Additionally can be used in conjunction with IncrediBuild.

You can learn more about the analyzer, as well as 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, as some of them are difficult to classify. This does not hurt to make a general impression, and in detail with the existing diagnostics can be found here .


Table 1 - PVS-Studio features. Click on the picture to enlarge it.

PVS-Studio for Linux

Now we’ll actually talk about why many people started reading this article: about supporting Linux.



This task is not as simple as it may seem at first glance. Compiling an executable for Linux and using it to check something is a simple task. We have long dealt with it. A year ago, we wrote an article about an experiment about checking Vim. However, this is only a small part of the total amount of work. Programmers forget that assembling an executable and creating a software product is not the same thing.

We plan to support GCC and Clang. We started with GCC, and we will return to Clang later. I'll tell you about the tasks that are now facing 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 life more difficult for themselves, and at the same time, developers who implement code highlighting, static analysis, and so on. In another way, I cannot explain why, for example, it was necessary to introduce Conditionals with Omitted Operands . Of course, it's cool that you can shorten the ternary operator to: z = x ?: y ;. In my opinion, without this you can absolutely safely manage and live a happy life.

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

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

Moreover, all sorts of "cunning" things like to use in the system header files. So in practice it is very easy to run into some kind of expansion.

If someone is interested in what is still being discussed, I can offer 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 the experience of working with Visual C ++, we still expect the presence of sublimates 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, if we use some other parser, it would not help us much. For example, if we rewrite the analyzer, taking Clang as a basis, we will still have to fight on our own with the GCC and Visual C ++ extensions.

2. 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. C ++ and C # code is checked.
2. Static code analysis for nightly builds. If the warning was not noticed, it will be revealed at the stage of the night assembly on the server. PVS-Studio checks C # and C ++ code. In addition, we additionally use Clang to test C ++ code. One time for C # code, FxCop was also used additionally. During the year, he never found anything useful, and we refused to use it. But Clang found errors a couple of times that PVS-Studio did not notice, and we found it rational to continue using it.
3. Unit tests at the level of classes, methods, functions. The system is not very developed, since many issues 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 level tests of specially prepared and tagged files with errors.
5. Functional tests confirming that we correctly parse the 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 at 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 projects in C ++ and 49 in C #. Comparing the old and new results of the analysis, we control that something has not been broken and we are honing new diagnostic messages.
7. Functional user interface tests. This refers to the testing of extensions (plug-in), which is integrated into the Visual Studio environment. We check that clicking on various buttons and menu items leads to the desired results.

From the point of view of support for Linux, we need to first expand the item N5 and N6. Item N5 overlaps with the previous section "Fuller support for GCC and Clang." Making tests to check the system header files is easy, but time consuming to expand the parser. However, we have already spoken about this, and point N6 is much more interesting.

In fact, this is the largest and most complex testing system used by us. Here is how this program looks in the process:



It makes no sense to describe this tool in the article, since it is intended solely 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 add 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 on the selection of 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 verification time too long. On the other hand, they should be “saturated”: different projects should use different approaches to programming. That is, it is desirable that goto operators were actively used somewhere, templates were actively used somewhere, Unicode was actively used somewhere, 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

Standalone.exe GUI utility is included in PVS-Studio for Windows. With its help, 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 this utility you can check the project, assembled by any exotic or samopisnyy assembly system. However, this is not intended for exotic situations. Even if you have a classic makefile, it is easier to perform an analysis with Standalone, rather than deal with the PVS-Studio documentation, in order to write the analyzer's call to the maklefile.

Standalone allows you to track the launches of compilers Visual C ++, GCC (MinGW), Clang and collect all the information you need to check. It looks like this: you say the program “start spying”, after which you perform an ordinary build of the project. Then you say the program is "done." Starts the analysis of all those files that have just been compiled.

By the way, all this is not necessarily done manually. You can use the CLMonitor.exe utility to check the project on the server. It also collects information about running compilers and performs project validation.

Implementing the Linux version, we immediately decided that it was necessary to support tracking the compiler runs. This will help programmers to quickly and easily get acquainted with the PVS-Studio analyzer. The fact is that, using this utility, the project will be able to test any member of the team, without distracting people involved in supporting makefiles and the build system in general. In large projects, not everyone knows how their application is actually built. Moreover, not everyone will find the time and desire to understand how and where to register the PVS-Studio call. All this can be complicated by the presence of an autogenerated makefile. It is clear that everything can be sorted out, but this is a significant barrier to the first verification of the project and the satisfaction of research curiosity.

So you met another subtask to create a Linux version. We are working on developing a system for monitoring compiler launches and assembling all the necessary information for verification.

4. Documentation revision

When writing documentation, we always face opposing desires. On the one hand, we always tried to keep the product simple and understandable, and in order to work with it there was no need to get acquainted with a great guide. On the other hand, static analysis is a rather complicated tool, and the manual should reflect all the subtleties of working with it. This is especially true of 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 adjust and supplement the documentation sections on work in Linux. Plus, we need to figure out how to implement the ability for users to quickly receive information on a particular diagnosis. In Visual Studio there are no problems with this - 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 - you have to think. Of course, there is always a PDF file (350 pages) or online documentation on the site, but this cannot be called a convenient way to access the description of diagnostics.

5. Finalization of the site

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

6. Other: testing, distribution, support organization

Naturally, do not forget about testing. Although multi-level tests will reveal most of the problems, some completely unexpected errors or shortcomings will most likely manifest themselves. Now it is even impossible to assume that this will happen, but we have no illusions about the ideality of the world. Under Windows, we are faced with a variety of situations where it seems we are not to blame, but something is not working properly. I spoke about some of these unpleasant surprises in an interview about 2 years ago (look for the phrase “Unfortunately, the beauty and reliability of the internal code sometimes falls apart due to the effects of a hostile environment”). I'm sure there are similar surprises waiting for us in Linux.

The results of our work should be wrapped in a distribution kit, which can be easily downloaded and used. To say this is much easier than to do. I think it will take more than one iteration to make it convenient and take into account various subtleties.

One last thing: we must organize support for the new direction. Our users appreciate us for 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 ready for this.

7. Plans for the future

Above, I have described far from everything that we will need to spend time in order to adapt PVS-Studio to Linux. There are lots of smaller tasks that you don’t immediately remember, 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 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 with Clang. I still don’t even know whether the first release version of PVS-Studio for Linux will support Clang or not.

Here are some of the bigger challenges that await us:

• Integration with Qt Creator.
• Integration with ... (time will tell).
• Refinement 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 incorrectly using functions. It is worth expanding these tables with many of the functions described in POSIX.

In progress

We look forward to when something can be presented to the world. I hope I am interested in you, and many Linux developers want to try checking out 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 test the operation of PVS-Studio for Linux, please write to us. To make the letters easier to process, 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 briefly introduce yourself. We will be grateful to everyone who responds, but first of all we will pay attention to those people who can potentially become our clients over time.

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

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

When there is a version that you can try, we will write letters to all responding.

Thank you 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!