PVS-Studio теперь работает и без среды Visual Studio или C++Builder – проверяем препроцессированные файлы от чего угодно

    Новинка в PVS-Studio!

    В вышедшей на днях новой версии статического анализатора кода PVS-Studio 5.10 появилась маленькая незаметная утилита PVS-Studio Standalone. Как говорится, маленький шаг для человечества и большой шаг для PVS-Studio :). Эта утилита уже сейчас позволяет делать (пока) две вещи:

    • Просматривать без запуска Visual Studio IDE результаты анализа (.plog-файл), сохраненные на другой машине.
    • Анализировать уже препроцессированные файлы (полученные каким-либо образом) без запуска препроцессора и без файлов проекта или makefile-ов.


    При этом поддерживается полная навигация по коду, все настройки PVS-Studio, а также табличное представление результатов анализа, про которое я писал ранее. Это табличное представление позволяет использовать полный набор фильтров и сортировок диагностик с тем, чтобы максимально удобно работать с большим количеством сообщений.

    В этой статье я покажу два сценария полезного использования этой утилиты.



    Сценарий первый – просмотр .plog файла на машине без среды Visual Studio или C++Builder


    Предположим, вы по какой-то причине не имеете на своей рабочей машине ни C++Builder (что еще можно объяснить), ни Visual Studio (что уже вообще за гранью!). Но при этом начитались статей про то, что PVS-Studio это очень круто и не прочь взглянуть на результаты анализа кода. Поскольку вы не имеете поддерживаемых PVS-Studio сред разработки на своей машине, то вы можете попросить коллегу проверить проект в Visual Studio на другой машине, сохранить результаты проверки в .plog файл и принести его на свою машину (желательно вместе с исходниками проекта, чтобы удобнее было разбираться с ошибками). Что нужно для этого?

    Подготовка к проверке на машине со средой


    1. Развернуть PVS-Studio на той машине, где все-таки будет проверяться проект и есть среда разработки с интегрированной туда PVS-Studio.
    2. Настроить переменную SourceTreeRoot в настройках PVS-Studio) так, чтобы она содержала путь до начала файлов с кодом проекта (проверяемых файлов). Это делается для того, чтобы в .plog-файле были относительные пути, а не абсолютные.
    3. Выполнить проверку проекта и сохранить файл отчета.

    Просмотр отчета на машине без среды


    1. Установить PVS-Studio Standalone (выбрать галочку во время инсталяции).



    2. Запустить PVS-Studio Standalone из Windows-меню Start/Пуск.



    3. В запустившейся программе открыть .plog файл.



    4. Загрузился .plog:



    5. Отчет уже можно просматривать, но если кликнуть по сообщению, то увидим просьбу указать папку с исходниками:



    6. Сделаем это:



    7. И теперь можно просматривать лог, работать над фильтрацией и сортировкой сообщений и даже править исходный код!



    Конечно, отнеситесь с пониманием к этой нашей «среде» – она хоть и построена на Scientilla (как и Notepad++), но до IDE уровня Visual Studio ей как до Луны. Самое главное неудобство – отсутствие IntelliSence. Мы пытаемся его компенсировать диалогом поиска. Тем не менее:
    1. Вы можете просматривать диагностические сообщения анализатора и осуществлять навигацию по коду.
    2. Вы можете скрывать сообщения, фильтровать, отключать отдельные диагностики БЕЗ перезапуска анализа.
    3. Вы можете размечать сообщения как ложные срабатывания.
    4. В общем, это практически полноценная PVS-Studio, разве что без инкрементального анализа.
    Но наверняка многим будет интереснее второй сценарий использования, о котором далее.

    Второй сценарий использования – проверка препроцессированных файлов


    Но самое крутое в PVS-Studio Standalone – это не работа с готовыми логами, а возможность проверки препроцессированных файлов. Вообще в чем сложность интеграции PVS-Studio в произвольный проект? Дело в том, что для своей работы анализатор должен выполнить препроцессирование файлов. И если у вас есть проектный файл .vcproj/.vcxproj (т.е. вы работаете в среде Visual Studio) или даже вы работаете в C++Builder, то создание препроцессированных файлов для PVS-Studio происходит автоматически, когда вы нажимаете кнопку «Проверить». А вот если вы вдруг работаете в другом режиме (например, через Makefile), то вам надо интегрировать вызов PVS-Studio в сборочную систему, что не всегда бывает легко по разным причинам.

    И тут наш новый инструмент PVS-Studio Standalone как раз в тему. Вы можете ему подсунуть препроцессированные файлы, и он их проверит, найдет ошибки, и даже сопоставит с исходниками. То есть сообщения об ошибках будут на исходные файлы с кодом, а не готовые препроцессированные файлы. Посмотрим как это делается на практике?

    Тестировать PVS-Studio Standalone я буду на… ну скажем zlib. Нет, нет, это не статья об ошибках, найденных в zlib. Не удивляйтесь, что почти не будет предупреждений. Там нет ошибок. Плюс PVS-Studio много раз проверял код zlib в других проектах и все ложные срабатывания на zlib мы давно победили. Эта статья должна показать, как использовать новый инструмент, а не какие ошибки мы нашли в каком-нибудь проекте. Поэтому я буду использовать относительно простой проект, чтобы все поняли, как такое повторить.

    Сборка zlib


    1. Качаем zip-файл, распаковываем в zlib-1.2.8, кладем в корень (в zlib-1.2.8) файл win32\Makefile.msc.
    2. Настраиваем сборочное окружение командной строки с помощью VS2012 x86 Native Tools Command Prompt (или чего-то другого).
    3. Запускаем nmake –f Makefile.msc.
    4. Убеждаемся, что все скомпилировалось.

    Получение препроцессированных .i-файлов


    1. Открываем на редактирование файл Makefile.msc

    2. Добавляем ключ /P генерировать препроцессированные файлы. То есть вместо строки

    CFLAGS = -nologo -MD -W3 -O2 -Oy- -Zi -Fd«zlib» $(LOC)

    получаем

    CFLAGS = -nologo -MD -W3 -O2 -Oy- -Zi -Fd«zlib» /P $(LOC)

    3. Генерируем препроцессированные файлы:

    nmake –f Makefile.msc clean

    nmake –f Makefile.msc

    4. Убеждаемся, что в папке есть .i-файлы.

    Проверка файлов в PVS-Studio Standalone


    1. Запускаем PVS-Studio Standlone.

    2. Открываем меню Tools, команду Verify Preprocessed Files…



    3. Заполняем поля следующим образом:



    Что здесь важно: пути до исходников и до .i-файлов (они у нас совпадают), пути до системных include-папок (чтобы не ругаться на сообщения в этих файлах), ну и некоторые дополнительные параметры.

    Интерес представляет список поддерживаемых препроцессоров. Вот он более подробно:



    Давний читатель наших статей тут же воскликнет: «Это что же, вы наконец-то gcc поддерживаете?» Отвечаем: «Поддерживаем!». Поддерживаем и в случае MinGW, и в Cygwin, и в случае (О Боже, они сделали это!) Linux.

    То есть теперь вы можете даже проверять linux-проекты, хотя мы только начинаем тестировать эту функциональность честно говоря. У кого будет желание играться и экспериментировать – пишите о своих проблемах, будем оперативно править, если что-то у кого-то вылезет.

    4. Заполнив диалоговое окошко, нажимаем кнопку Start. После некоторого времени, получаем окно с результатами и навигацией:



    Можно проверять и ПРАВИТЬ код прямо в PVS-Studio Standalone!

    Мы сделали очень крутую штуку, которая расширяет сферу применения PVS-Studio и делает это очень удобным для пользователя способом.

    Что дальше?


    А дальше каждый, кто просил у нас проверку MinGW, Cygwin, gcc, а также по каким-то причинам просто не мог проверить свой код с помощью PVS-Studio, должен скачать новую версию и поиграться с PVS-Studio Standalone.

    P.S. И да, это первая статья про PVS-Studio с таким большим количеством скриншотов :-).
    PVS-Studio
    411.81
    Static Code Analysis for C, C++, C# and Java
    Share post

    Similar posts

    Comments 18

      +2
      В дополнение к словам коллеги о режиме независимой проверки препроцессированных файлов, хочу отдельно подчеркнуть, что смысл использования такого режима состоит прежде всего в его простоте. По нашему опыту, в большинстве сборочных систем проще добавить к параметрам компиляции всех файлов ещё один флажок, чем встраивать вызов анализатора «параллельно» с компилятором. И хотя прямая интеграция анализатора в сборочный процесс безусловно является «идеологически» более верным решением, такой вариант не всегда удобен, чтобы быстро «попробовать» анализ на своём проекте.
        0
        Пардон за ламерский вопрос, а разве разные препроцессры работают по-разному?
        Я думал, уж что-что, а простая макроподстановка должна работать одинаково…
          +1
          Да, по-разному (к нашему сожалению), и оказывается даже довольно сильно. У нас есть внутренний список отличий/проблем в разных препроцессорах — это сильно усложняет нашу жизнь.
            0
            Ого. А в чем могут быть различия?
              +1
              Например, в некоторых разворачивается и исполняется завёрнутая в макрос #pragmа, что не соответствует стандартам, но сильно облегчает жизнь. Т.е.
              #define ALIGN4 #pragma pack(4)
              ALIGN4
              не должно работать, но работает. Кажется даже в GCC есть на этот случай исключение. И тому подобные вещи. Сравнения всякие находил по-разному работающие. А уж математика…
                0
                Понял, спасибо.
                  0
                  Хм, по стандарту это бы превратилось в "pragma" pack(4) или что-то подобное?
            0
            Не пробовали проверить своим анализатором linux kernel, или различия C и С++ не дают этого сделать?
              0
              Не всё сразу. :)
                +3
                У нас анализатор и C, и С++ поддерживает.

                Пробовали. Статью пока не написали, так как там ОЧЕНЬ сложный код, который ОЧЕНЬ сложно читать и понимать, есть ли там ошибка или нет.
                  0
                  Ясно, спасибо
                +1
                Поддержку Apple OS X и плагин для интеграции в Xcode не думаете реализовать?
                  0
                  Пока нет.
                    0
                    На самом деле, плагин для Xcode — это вообще не обязательно, да и помоему официальных путей сейчас нет. Но можно проще — у Xcode есть папка DerivedData — куда собственно и падают, все промежуточные файлы сборки проекта. Там много чего, но в том числе есть и d/dia/o файлы. Сейчас пропробую проверить чтобы он туда и i файлы добавлял. Т.е. по хорошему пути к этой папке вам достаточно, чтобы запустить свой анализатор.

                    Другое дело, то что clang там например такой сейчас
                    Apple LLVM version 5.0 (clang-500.2.75) (based on LLVM 3.3svn)
                    Target: x86_64-apple-darwin12.5.0
                    Thread model: posix

                    И он может таки отличатся, от стандартного.
                    0
                    Что мешает пользоваться уже существующим решением с проверкой .i-файлов?
                    +2
                    Очень полезный инструмент, мы с его помощью много редких ошибок нашли. Спасибо за ключик.

                    p.s. О, FlylinkDC на 6 скриншоте.
                      0
                      На мой взгляд, главный плюс отдельной утилиты, а также главный сценарий это встраивание в среду непрерывной интеграции (Jenkins/TeamCity). Но ограничивающим моментом я вижу отдельный формат результатов с собственным просмотрщиком.
                      Должен быть XML/HTML или даже txt, но главное формат который можно просмотреть в браузере.
                        +3
                        У нас УЖЕ и xml, и txt, и встраивание в среду непрерывной интеграции…

                      Only users with full accounts can post comments. Log in, please.