|This section describes restrictions of a trial mode of PVS-Studio on Windows. To enable the analyzer work on Linux a license file is needed. In case if you want to try the analyzer on Linux, please, write to us.|
After downloading, first installation and run, PVS-Studio analyzer starts working in the trial mode. This mode imposes certain restrictions on the available features of our product. However, the trial mode allows you to start using the tool immediately after installation without any additional steps, such as registration on the site or a license key request. The main function of the analyzer, which is detecting and fixing real errors, is available out of the box.
So, just by downloading the analyzer and running a check, you can benefit your project without worrying about complicated configuration or licensing issues and prices. Of course, it will be only a small fraction of what a full and regular use of all abilities of PVS-Studio will provide.
Limitations of the PVS-Studio analyzer have two purposes. The first - to show a potential user that a static analyzer is able to find bugs in the code. The second - to prompt the user to communicate with us via e-mail so that we could help use the tool correctly.
Let's talk about our recommendations and existing limitations of PVS-Studio Trial mode.
We will list all the restrictions imposed by the trial version on PVS-Studio abilities.
As you can see from the list, all limitations of trial version can be divided into 2 groups - limitations on the total number of analyzer messages, available for viewing, and restrictions on the usage of the additional functionality of the analyzer. Now we'll consider these groups of restrictions in more detail.
First, let's talk about the restriction of the number of messages that can be viewed in trial mode. Let me remind you that we have a limited number of clicks along the messages in plugin interface \ Standalone.
The most common wrong behavior pattern: a programmer turns on all the warning settings to the maximum. This is our biggest pain. They enable all types of warnings (general-purpose, 64-bit ones, optimizations), all levels of warnings; some people even manage to find our custom-built warnings and turn them on.
Programmers explain it by saying that they want to see everything that the analyzer is capable of. And this is totally wrong. A right aim would be to see how the analyzer could be beneficial for the project. That is, first of all, you should see that the analyzer can find real errors in the code. By turning all the warnings to the maximum, you have a chance to drown in the large amount of warnings. Having looked through 20-30 uninteresting warnings people lose interest. Most likely, the stage of familiarizing with the tool will end at this point. However, if the number of warnings that the person can see is decreased (by example, by filtering them out), the probability to discover serious errors will increase. Then the programmer will treat the tool differently. He will try to filter uninteresting warnings, customize the tool and learn about the ways to suppress false positives in macros and so on...
There is another point concerning a big amount of warnings. The programmer can be aware that he is looking at both high and low - certainty warnings and he is ready to look through a big number of messages. The trouble is that he quickly takes one's eye off the ball. Roughly speaking, having looked at 10 warnings, he will most likely miss the eleventh one that will point to a real issue.
Therefore, we recommend checking only High and Medium - certainty warnings when using the analyzer for the first time.
Now, some brief facts about the existing limitations of trial mode. There is a limited number of jump-clicks to the code that the user can perform.
Let's go through these restrictions and have a look at the reasons behind them. All the stories are based on true facts. These restrictions aren't made up by a market manager, they resulted from long communication with potential clients and observations of the way people get acquainted with PVS-Studio.
When a user is run out of the "jump-clicks", the program will offer to fill in a small form with contact details that we use to find out if we can help with anything else. After that, the user gets another portion of "clicks".
What's the point in contacting us? First of all, we can give a temporary key for a closer look at PVS-Studio. By this moment the programmer got used to the tool, found bugs in his code and now he is ready to see the warnings of other levels.
Secondly, what is important is that we want to help a person get familiar with PVS-Studio. You cannot even imagine, how large the amount of ways to use this tool incorrectly is. Here are some examples.
Someone may have a "nasty macro" and the analyzer issues a lot of meaningless warnings. That's how the person loses his "clicks" going to the code fragments. After that, asking a question "Is everything fine?", we get something like:
It's awful. How in the world people use this analyzer. I am sick of looking at the warnings of the Vxxx number.
This is when we help telling the person about various ways to suppress the warnings in macros or that the person can just turn off this diagnostic, for a start.
Another person complains that the warnings issued for the third-party libraries really bother him.
Then we give a hint that such warnings can be disabled in two clicks. Really, it's just 2 clicks.
In both cases we helped to make the life easier. If there was no communication, those people would continue thinking how terrible the analyzer is. And most likely won't even consider getting the license for the tool.
Further, we will consider the limitation in PVS-Studio trial mode on the usage of tools for deep integration of the analyzer into development processes.
After the first acquaintance with the analyzer (when it becomes more or less clear how to run a check and fix detected bugs), many users are tempted to immediately "dig deeper" and start using more advanced features of the product, such as: integration of analysis into build automation or continuous integration systems, automated mailing of newly found messages to developers, etc.
As you can see from the list of restrictions, many of our console utilities are not available in trial mode. This was made for a reason. According to our experience of communicating with our users, it is very common when a person starts using such tools of "deep" integration not in the optimal way, or often his approach is wrong altogether.
Here are some examples from our real communication with our users. Some of these users are our clients. Unfortunately, the general recommendation to "read the documentation beforehand" is not always working: in some cases, people are too lazy to read it, and sometimes it is not enough to read only one part to assess the whole picture.
First example: the user runs a PVS-Studio_Cmd command-line utility for a check of his solution on a build server. The result of its work is the report plog file in XML format. Next, the user attempts to parse the report himself to put the results into his bug-tracking system. Here he faces the fact that the plog report (and we strongly recommend that our users should not try to parse it on their own!) contains warnings that were suppressed through Suppression of false alarms. The user then angrily writes us about the bug in our tool - "your report contains the error messages, that I have already suppressed!". But the user hadn't taken into account that in plog file, false alarms messages are marked in a special way. We intentionally preserve such suppressed reports in a plog, as in some cases, you may need to quickly view them without restarting the analysis and without a need to remove false alarm markup from code. In this situation, we recommend that person to use our PlogConverter tool to filter and transform plog report into a more appropriate format suitable for his tasks.
Another example: the user configures an automated mailing of analysis results using the BlameNotifier tool (or SonarQube). At the same time, he runs the analysis of a very large project, containing millions lines of code. Of course, because of such a huge code base, the analyzer starts issuing thousands of warnings. Some of them may be false alarms, and some of them are real errors, but that is not the point here. Due to the huge number of warnings, which begin to shower on developers, they start to see these notifications as spam, since it is impossible to view at once such a large number of warnings. As a result, having received several "spam" mailings, a developer can get a negative impression of the analyzer, and then we will not get a license renewal for the next year, bugs in the project won't get fixed - as a result, both sides will lose. We recommend, if you start using the analyzer for such a huge project, first suppress all old messages, and immediately begin to use our analyzer for fixing errors in your newly written code. You can always return to the old messages later, gradually filtering out false positives among them and finding real errors.
Therefore, before starting to use the "advanced" modes of PVS-Studio, we ask our users to contact us and describe the desired scenario of using the tool. We are always ready to advise the optimal way, in terms of the opportunities available in PVS-Studio, and how to solve a particular problem. In addition, we can give a fully functional license without any trial restrictions for a limited period to test "deeper" abilities of the analyzer.
Here is what we can say to those who aren't new to the static analysis tools. It's all very simple. Contact us and we will give you a temporary key for a deeper exploring of the analyzer, without the restrictions imposed by the trial version.