“PVS-Studio developers, have you heard about Clang?”, Or a comparison of PVS-Studio and Clang without code

    Quite often, when we write articles about the PVS-Studio static code analyzer C ++, we are asked one of the following questions:
    1. And why is PVS-Studio better than Clang?
    2. But Clang is free, and you cost money - it’s not clear why?
    3. Clang is better, you can easily add your own diagnostics there, it's open source!
    4. You have to close, Clang will crush you, if not now, then when they will debug the version for Windows. (Well, it's not even how the question is formulated).
    The time has come to answer these questions in detail.


    I'll start with a little joke. PVS-Studio is better than Clang, if only because PVS-Studio found errors in the Clang code ( one , two ), but Clang in the PVS-Studio code did not.

    Compare code analysis tools is not an easy task (I already wrote on this topic ). It is incorrect to compare static analysis tools only by a set of diagnostic rules. Indeed, in ordinary life, tools are used not in tests, but in real projects. And then it turns out that the static analysis tool has two phases - implementation in an existing project and regular use.

    Let's look at how a person tries, for example, Clang. Perhaps a person takes several small test files with software errors, runs the analyzer on them and sees that the analyzer found something, did not find something. Suppose a person liked the triggered diagnostics. After that, he tries the analyzer on his real project and sees hundreds, or even thousands of messages from the code analyzer. He cannot fix them all at once, he cannot do something with them - it is unclear what, because a Clang type analyzer simply displays them in the console. It is at this point that the implementation of the analyzer should begin.

    The goal of the stage of introducing static analysis into an existing (and therefore large) project is to receive diagnostic messages on code 0 when the analyzer starts.And here it turns out that Clang has nothing to offer. It simply does not have mechanisms to work with a large number of messages. Well, except how to manually go through each message and make changes if necessary.

    What can PVS-Studio offer? A lot of things:
    1. An exception to the analysis of individual files, mask files or folders.
    2. Filter messages by error code or message content.
    3. Different ways to sort messages.
    4. Marking up messages as false alarms (False Alarm) for their further concealment.
    5. And much more.
    The key point is that all these functions work in real time without the need to restart the analysis. This is very important, since on large projects, the code can be checked for a long time.

    Why does PVS-Studio have such opportunities to simplify the implementation phase, but Clang does not have them? The fact is that the presentation of the analysis results in PVS-Studio is a table (as in the figure):

    Figure 1 - Presentation of PVS-Studio analysis results.


    Figure 1 - Presentation of PVS-Studio analysis results.

    More precisely, a table is a visual representation, but inside it is a database, with all the potential for filtering and processing this data. In the case of clang, this is the output to the console. Of course, when we integrate clang into the development environment, we get navigation, but nothing more. And this means that we are approaching the main difference between PVS-Studio and Clang.

    As part of PVS-Studio, there are ways to implement the tool (nullifying the number of messages on an existing project), but not as part of Clang. It doesn’t seem important when you just read articles on the Internet about code analysis, but it comes to the fore when you try to incorporate static analysis into your project, which is already several years old.

    It may seem that I deliberately avoid comparing PVS-Studio and Clang in terms of diagnostics. Yes and no. The task of comparing the diagnostic capabilities of tools is complex in itself. But moreover, the results of such a comparison very quickly become obsolete. And we, working on PVS-Studio, and the Clang developers all add new diagnostics.

    If someone says: “I run clang and I have 0 diagnostics, although I did not do any implementation,” then this person simply uses the already implemented tool. That's all.

    Now to the question of why Clang is free, and PVS-Studio costs money. Programmers do not always think about the means by which they get paid. Clang is working on programmers from Apple, Google, Intel. We are developing PVS-Studio as an independent project and are forced to earn a salary ourselves, therefore PVS-Studio is a paid product. Naturally, we do not oblige anyone to use it. Our customers are those PVS-Studio users who need this product and who understand "what is there to pay for".

    Although the analyzer in Clang is an open source project, adding a new diagnostic rule to a person who is not an expert in the field of code analysis will be quite difficult. But here you shouldn’t take a word, just try to add a new rule to Clang, if it is relevant to you.

    And finally, about whether we are afraid of competition with Clang. Not yet, as in Clang static analysis of this is just one of the many features of their tool, and we specialize in this. In addition, switching to a new compiler (and to use static analysis from Clang you need to compile it yourself) is quite difficult in itself for an existing project.

    However, this text does not mean that we somehow feel bad about Clang. This is a very good project, part of which is used in PVS-Studio (as a preprocessor), and a very large number of cool developers are working on it.

    Also popular now: