Blog

Evgeniy Ryzhkov

  • What do static analysis and search engines have in common? A good "top"!

    18.04.2012
    Developers of search engines like Google/Yandex and developers of static code analysis tools to some extent solve the same task. Both have to provide users with a certain selection of resources that meet users' wishes. Well, of course search engines' developers would like to confine themselves just to the button "I'm Feeling Lucky!", while developers of static code analysis tools want to generate a list of real errors only. But reality imposes constrains, as usual. Do you want to know how we fight the cruel reality while developing PVS-Studio?. Read more

  • PVS-Studio command line tips

    05.04.2012
    As a lesser portion of our users utilize the command line version comparing to the VS IDE version, I would like to point attention to several aspects of using the command line version, as these could be not quite obvious at a first glance. Read more

  • An ideal static analyzer, or why ideals are unachievable

    15.03.2012
    Being inspired by Eugene Laspersky's post about an ideal antivirus, I decided to write a similar post about an ideal static analyzer. And meanwhile think how far from being it our PVS-Studio is. Read more

  • Licensing of PVS-Studio: why don't we have Single User License?

    11.03.2012
    PVS-Studio has a rather simple licensing scheme now - the basic (usual) version is licensed for a team consisting of up to five developers. There is also the site license for large teams, but we won't dwell upon it here. Read more

  • How we managed the task of implementing trial mode in the PVS-Studio code analyzer

    01.02.2012
    Choosing and changing the model of trial mode is one of the most relevant and widely discussed tasks for many software developers. It is easy to make a model for some programs and difficult for others. And some people are haunted by the question: "Have we made everything right?" The task of choosing a trial-model is relevant to us, PVS-Studio developers, as well. We decided to share some of our ideas regarding this subject and tell you about a new alternative we have invented. We hope that our arguments and some ideas will be helpful to other developers too. Read more

  • Tips on speeding up PVS-Studio

    15.12.2011
    This note is obsolete. Please read "Tips on speeding up PVS-Studio" in documentation.. Read more

  • On the good of automated filtering of identical messages

    14.12.2011
    From the very beginning duplicates of messages in our analyzer PVS-Studio have been eliminated. For example, if a diagnostic message is generated for a code in an .h-file included into several .cpp-files, our tool will generate it only once. Some other analyzers don't do that and when they check .cpp-files, they show you messages every time on the same strings in .h-files. So it turns out that our analyzer generates fewer messages compared to such tools. But we had no chance to estimate how useful it is before. Now we've got such an occasion, and the results are really impressive. Read more

  • "Please check this project too..."

    13.12.2011
    We believe that the best way of promoting our static code analyzer PVS-Studio is using it to check famous open source projects (like Chromium, Clang, WinMerge and many others) and writing articles on the check results. This task is not so simple because, unfortunately, PVS-Studio is just a tool, not a magical program that can find all the errors itself. People often write to us asking to check this or that project and write an article on it. Read more

  • About our VivaCore library

    06.12.2011
    Those who are interested in the code analysis technology most likely have heard about our library VivaCore. It is this library our static analyzer PVS-Studio is based on. Earlier one could download the library from our site, but we have removed it recently and do not distribute it any more. Read more

  • What amazes me while developing the static code analyzer

    28.11.2011
    When developing any programmer tool, be it a compiler or a static analyzer, or anything else, it is naturally that programmers use test projects the tool is constantly ran on. For example, when developing our static analyzer, we run it on 70 real projects. It allows us to make sure that everything is alright and nothing is broken. Besides, when we develop new diagnostic rules, we can see the code fragments where the new errors have been detected, after running the tests. Everything is logical and obvious. But why did I entitle the post in that way?. Read more