“PVS-Studio developers, have you heard about Clang at all?”, Or a comparison of PVS-Studio and Clang without code
Quite often, when we write articles about the static analyzer C ++ code of PVS-Studio, we are asked one of the following questions:
I'll start with a little joke. PVS-Studio is better than Clang at least in that PVS-Studio found errors in the Clang code ( one , two ), and Clang did not in the PVS-Studio code.
Compare code analysis tools, not an easy task (I already wrote on this topic ). It is incorrect to compare static analysis tools only according to 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 - introduction into 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 program errors, runs the analyzer on them and sees that the analyzer has found something, has not found something. Suppose a person liked the diagnostics that worked. After that, he tries the analyzer on his real project and sees hundreds, or even thousands of messages from the code analyzer. It cannot fix them all at once, it is unclear what to do with them, because the Clang analyzer will simply output them to the console. It is at this point that the implementation of the analyzer should begin.
The goal of introducing static analysis into an existing (and therefore large) project is to receive diagnostic messages when the analyzer is started on code 0. And here it turns out that Clang has nothing to offer. It simply has no mechanisms for working with a large number of messages. Well, except how to manually go through each message and make edits if necessary.
What can PVS-Studio offer? A lot of things:
Why does PVS-Studio have such opportunities to simplify the implementation stage, while Clang doesn’t have them? The point is that the presentation of the analysis results in PVS-Studio is a table (as in the figure):
Figure 1 - Presentation of the results of the analysis of PVS-Studio.
More precisely, the table is a visual representation, and inside it is a database, with all the attendant possibilities for filtering and processing this data. In the case of clang, this is output to the console. Of course, when clang is integrated into the development environment, we get navigation, but nothing more. This means that we approach the main difference between PVS-Studio and Clang.
As part of PVS-Studio, there are ways to implement a tool (reducing to zero the number of messages on an existing project), but not as part of Clang. This does not seem important when you are just reading articles on the Internet about code analysis, but it comes to the fore when you are trying to implement static analysis in 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 didn’t 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 from which they receive their salaries. Over Clang work 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 clients are those users of PVS-Studio 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 code analysis will be quite difficult. But here you shouldn't take a word, just try adding a new rule in Clang, if this is relevant to you.
And finally, about whether we are afraid of competition with Clang. Not yet, since in Clang static analysis of this is just one of the many possibilities of their tool, and we specialize in this. In addition, switching to a new compiler (and to use static analysis from Clang you have to compile it) is quite difficult in itself for an existing project.
However, this text does not mean that we somehow have a bad attitude to 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.
- And how is PVS-Studio better than Clang?
- But Clang is free, and you are worth the money - it is not clear why?
- Clang is better, you can easily add your own diagnostics there, because this is open source!
- It's time for you to close, Clang will crush you, if not now, then when you debug the Windows version (well, this is not even how the question is formulated).
I'll start with a little joke. PVS-Studio is better than Clang at least in that PVS-Studio found errors in the Clang code ( one , two ), and Clang did not in the PVS-Studio code.
Compare code analysis tools, not an easy task (I already wrote on this topic ). It is incorrect to compare static analysis tools only according to 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 - introduction into 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 program errors, runs the analyzer on them and sees that the analyzer has found something, has not found something. Suppose a person liked the diagnostics that worked. After that, he tries the analyzer on his real project and sees hundreds, or even thousands of messages from the code analyzer. It cannot fix them all at once, it is unclear what to do with them, because the Clang analyzer will simply output them to the console. It is at this point that the implementation of the analyzer should begin.
The goal of introducing static analysis into an existing (and therefore large) project is to receive diagnostic messages when the analyzer is started on code 0. And here it turns out that Clang has nothing to offer. It simply has no mechanisms for working with a large number of messages. Well, except how to manually go through each message and make edits if necessary.
What can PVS-Studio offer? A lot of things:
- Exclusion from analysis of individual files, files by mask or folders.
- Filtering messages by error code or message content.
- Various ways to sort messages.
- Markup messages as false alarms (False Alarm) for further concealment.
- And much more.
Why does PVS-Studio have such opportunities to simplify the implementation stage, while Clang doesn’t have them? The point is that the presentation of the analysis results in PVS-Studio is a table (as in the figure):
Figure 1 - Presentation of the results of the analysis of PVS-Studio.
More precisely, the table is a visual representation, and inside it is a database, with all the attendant possibilities for filtering and processing this data. In the case of clang, this is output to the console. Of course, when clang is integrated into the development environment, we get navigation, but nothing more. This means that we approach the main difference between PVS-Studio and Clang.
As part of PVS-Studio, there are ways to implement a tool (reducing to zero the number of messages on an existing project), but not as part of Clang. This does not seem important when you are just reading articles on the Internet about code analysis, but it comes to the fore when you are trying to implement static analysis in 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 didn’t 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 from which they receive their salaries. Over Clang work 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 clients are those users of PVS-Studio 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 code analysis will be quite difficult. But here you shouldn't take a word, just try adding a new rule in Clang, if this is relevant to you.
And finally, about whether we are afraid of competition with Clang. Not yet, since in Clang static analysis of this is just one of the many possibilities of their tool, and we specialize in this. In addition, switching to a new compiler (and to use static analysis from Clang you have to compile it) is quite difficult in itself for an existing project.
However, this text does not mean that we somehow have a bad attitude to 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.
Source: https://habr.com/ru/post/196956/
All Articles