This post contains a FAQ for those who have read our articles.
Yes. We try to inform developers that we have found certain errors in their project using PVS-Studio. Usually we send them a letter with a link to the corresponding article or write a post into the Bug Tracker. We also offer them a registration key for some time for them to work with PVS-Studio and study the diagnostic messages we haven't mentioned in the article.
Why do we "try", not "certainly inform"? On rare occasions, our e-mails are put into the spam folder, while messages in the Bug Tracker are deleted because they contain links and are also considered as spam. It's a pity, but what can we do?
Yes. As soon as we got this opportunity, we started launching night tests during which the analyzer checks itself and a report is sent to us via e-mail.
We did not keep record of interesting errors detected by PVS-Studio in itself. That's why, unfortunately, it's impossible to write an article titled "Checking PVS-Studio with PVS-Studio". Besides, we have not received e-mails with error reports for a long time by now. This is because we use incremental analysis that helps us fix detected errors long before the code gets into the version control system.
If you want to know more, you are welcome to read the article "How we test the code analyzer".
It's expensive and difficult to implement this version. Perhaps the Linux-version will appear some time, but it is not in our nearest plans. We see no point in investing large amounts of resources into the direction where it is difficult to profit from sales.
The belief that it is difficult to earn enough in the Linux world is based on the personal experience of participating in a certain project. There are also some indirect evidences. For example, the AQtime Linux edition version is not developed and supported anymore. It means that it's quite difficult to make on programming tools in the Linux world.
From the technical viewpoint, it is possible to port PVS-Studio.exe's code to another platform, as it almost doesn't use any Windows-specific functions.
To create PVS-Studio for a different operating system you should provide at least the same quality level on that platform as on the Windows platform. To maintain PVS-Studio's quality level we use a lot of various test types: static analysis, unit tests, functional tests, UI tests, etc. It is only after passing all these tests that we can be convinced that the analyzer behaves in the same way on the other platform as it does on Windows. Testing the analyzer comprises about 30% of the general development price.
Besides, you should take into account that files with code processed by the Visual C++ compiler contain certain constructs specific to this compiler. And PVS-Studio does support them. Other compilers (GCC, for instance) contain specific constructs as well, and we will have to implement support for them. It is an unapparent yet huge amount of work. The fact that the key word '__restrict' is used 10 000 times rarer than 'for' doesn't mean that we can do without making support for it. Many programmers are unaware of such things as __w64, __noop, __if_exists, __int3264, __uuidof, __based, __LPREFIX and so on and so forth.
Finally, different systems have different sets of include files used by programmers. So while PVS-Studio handles Visual C++ include files it doesn't mean that everything will work as well with GCC include files.
This is not the restriction of PVS-Studio. None of the Visual Studio Express Edition versions supports plugins - this is the restriction of this very Visual Studio edition; we cannot integrate our tool into Visual Studio Express Edition.
Nothing.
PVS-Studio is the abbreviated name of our company "Program Verification Systems" plus the word "Studio".
PVS is Prototype Verification System.
It's just an accident that the both words contain "PVS".
PVS-Studio's price is adequate. Those who purchase PVS-Studio usually don't speak on the price and discounts because they really need the tool. Those who speak of a high price don't need PVS-Studio. That's why any price will be too high for them.
We checked this through an experiment: people often tell us about a too high price and say that it should rather be $100-$200. So we started to offer these people to buy PVS-Studio at the price they suggest ($100-$200). Almost nobody did. The conclusion is: these are idle commentators who are not interested in their code's quality and who simply don't need PVS-Studio.
It is support that is very expensive. Only static analyzer's developers can answer any questions concerning it. We do not get questions like "how can I download the file?" or "what is the float type?". Our customers are programmers who ask complicated questions on the C++ language or report errors accompanied by crash stack printing. Only programmers can deal with such requests.
It might happen due to the following two reasons:
1) You have already fixed the errors PVS-Studio could have found through other testing methods. And it has cost you much more than using PVS-Studio. This subject is discussed in detail in the following articles:
2) You get false positives and your attention is quickly weakening. As a result, you miss real errors. This is a very big trouble and we don't know yet how to solve it. This discussion on the reddit.com website is very characteristic regarding the subject.
A person reads the following text in the article:
Fragment N1.
Diagnostic message V511.
The sizeof() operator returns size of the pointer, and not of the array, in 'sizeof(src)' expression.
ID_INLINE mat3_t::mat3_t( float src[ 3 ][ 3 ] ) {
memcpy( mat, src, sizeof( src ) );
}
Correct code:
memcpy( mat, src, sizeof(float) * 3 * 3);and tells us we are wrong and there's no error:
Fragment N1.
Except it doesn't. The sizeof() operator returns the size of the object, and src is not a pointer - it is a float[3][3]. sizeof() correctly returns 36 on my machine.
We thoroughly explain why he is incorrect. Then he gets surprised and thanks us:
Oop - yup - I essentially tested with with "char A[100];" rather than "void Foo(char B[100])"
It appears that he has even created a test sample to check what he has read. But the sample was written incorrectly. Imagine how much time the person has spent to analyze the error and write the test sample but still failed to understand the point!
By the way, similar complaints can be found in the wonderful article "A Few Billion Lines of Code Later - Using Static Analysis to Find Bugs in the Real World". The point is this: if the first 10 messages reviewed by the programmer have appeared false positives, he/she starts to take all the following messages as false positives too.
By the way, the above said again confirms the fact that customer support is a very important and expensive task.