From the basement of the secret laboratory of PVS-Studio developers ...

    Oh, an interesting article about PVS-Studio!
    From time to time, we talk about our internal research and development that takes place in the development team of the PVS-Studio static code analyzer for C / C ++. Today's story is about another new product that we are preparing as part of our product.

    Those who follow our project (and even more so use it) know that our analyzer was originally a plug-in only for Visual Studio. Then it became possible to use it as a console application built into the Makefile (ask me how if you don't know). Then, at the beginning of this year, we had integration into C ++ Builder. By the way, we still have quite a few users under C ++ Builder, and we do not quite understand why. And recently, we were thinking about the so-called standalone application.



    In general, what does an ideal static code analyzer look like for a user (in a vacuum or not)? It seems to me, based on my experience in this area, the ideal analyzer should look like this. The user downloads the utility, launches it, indicates the folder with the code and presses the big green button: “Find all errors!”. No customization, no "integration into the project." After all, the user does not need this? Yes, no need. But you need a code analyzer, unfortunately. At a minimum, we need information on #include and #define if we are talking about C ++. It is needed in order to preprocess the code.

    And here we come to the need to choose one of the options:
    1. Or the tool itself must extract this information from the project file (as our plugins for Visual C ++ and C ++ Builder do).
    2. Or the tool can receive this information if it is passed to it in the Makefile (how our version for the command line works).
    3. Or the tool makes the user painfully drive all the folders for #include and #define parameters, which is almost impossible, because it is extremely difficult for the user to do this.
    4. Or ... come up with some other option.

    We went the fourth way and decided to try this. But what if, as initial information, the analyzer receives not ordinary sources in the form of .cpp files, but already preprocessed files . Those. files that are processed by the preprocessor. This will save us from having to call the preprocessor, and accordingly know these #include and #define.

    Of course, this does not coincide with the ideal analyzer option described above. But on the other hand, this allows you to use PVS-Studio for almost any C / C ++ project, no matter in which development environment you run it.

    So, the tool being developed in the secret laboratories of our team looks something like this:
    Figure 1 - Dialog for starting pre-processed file verification.
    Figure 1 - Dialog for starting the verification of preprocessed files.

    First, we indicate the folder where the preprocessed .i files are located. They will be analyzed by our tool.

    Secondly, we specify the source folder. This is necessary in order to identify errors more accurately. In addition, it is always better to do (in the future) navigation on user .cpp files, and not on .i files that are not quite understandable to a person.

    Thirdly, we indicate the folder in which the system include-files are located. The most basic ones, like or . For what? In order for the analyzer to know that these are the files to which it is not necessary to issue diagnostic messages.

    So, we can “feed” the preprocessed files to this program, and then run the analyzer on them. This is how we are currently testing the Boost project. By the way, there will be a Boost check report soon - subscribe to our blog so as not to miss. After checking the files, we get a list of diagnostic messages like this:
    Figure 2 - List of diagnostic messages after checking i-files.
    Figure 2 - List of diagnostic messages after checking i-files.

    I draw the attention of readers to the fact that this is not Visual Studio or RAD Studio. This is a separate utility that repeats the full (or rather uses) the PVS-Studio window. It also has a built-in code editor (Scintilla from Notepad ++), which allows you to work with errors quite fully:
    Figure 3 - A full-fledged code editor.
    Figure 3 - A full-fledged code editor.

    Naturally, this post does not draw on a full description of our new secret utility. However, I can already answer a few questions.

    Who does NOT need this utility? For those who can easily check their project in PVS-Studio using integration in Visual Studio and C ++ Builder. Who needs this utility? For those who want to test their code using PVS-Studio and use other development environments and / or project files, into which it is difficult to embed our command line utility.

    How would you like to see such a utility? Is the check mode for ready-made preprocessed files convenient for you? What is missing in such a utility? Should we release it or abandon further development of this utility, since everyone is happy with our integration into Microsoft / Embarcadero environments?

    PS By the way, we updated the design of our database of errors detected in open source projects.

    Only registered users can participate in the survey. Please come in.

    The utility described in the article ...

    • 68% ... very useful, I’ll definitely try it when release 196
    • 31.9% ... it’s not clear who needs it, the guys are doing something wrong 92

    Also popular now: