Pvs studio ��� linux

Знакомство со статическим анализатором PVS-Studio при разработке C++ программ в среде Linux

PVS-Studio поддерживает анализ проектов на языках C, C++, C# и Java. Использовать анализатор можно под системами Windows, Linux и macOS. В этой заметке речь пойдет об анализе кода, написанного на C и C++ в среде Linux.

Установка

Установить PVS-Studio под Linux можно разными способами, в зависимости от типа дистрибутива. Наиболее удобный и предпочтительный способ – использование репозитория: так это позволяет автоматически обновлять анализатор при выходе новых версий. Второй вариант – использовать установочный пакет, который можно скачать здесь.

Команды, которые необходимо выполнить для установки, зависят от дистрибутива Linux, который вы используете. Например, для систем, основанных на Debian, установка из репозитория выглядит так:

Чтобы установить PVS-Studio из установочного пакета, можно воспользоваться утилитой gdebi:

Более подробно процесс установки описан в разделе «Установка и обновление PVS-Studio в Linux» документации. Там же вы можете найти информацию о системах, не основанных на Debian.

После установки нужно ввести лицензионные данные. Для этого используется команда

Где NAME и KEY – имя, на которое зарегистрирована лицензия, и лицензионный ключ. Необязательный параметр –o позволяет задать путь, по которому будет сгенерирован файл лицензии. По умолчанию он хранится в каталоге

Триальный ключ вы можете получить на странице «Скачать и попробовать PVS-Studio».

Проверка проектов

После установки анализатора можно приступать к проверке проектов. Для этого существуют два основных способа:

1. Мониторинг компиляции;
2. Запуск в процессе сборки непосредственно из сборочной системы.

Рассмотрим сначала первый способ. Чтобы запустить мониторинг под Linux, понадобится утилита strace. Анализатор использует ее для сбора информации о том, какие процессы запускались во время сборки проекта.

Запуск производится следующей командой:

В этом примере используется сборка с помощью make, но на месте вызова make может стоять любая другая команда, которую вы используете, чтобы начать сборку. Параметры командной строки в нее можно передать обычным способом.

После сборки strace создаст файл, который анализатор будет использовать для проверки исходного кода. Запустить анализ можно командой

На выходе получится закодированный файл с результатами, который вы можете сконвертировать в один из поддерживаемых форматов. Работу с отчетами мы рассмотрим в следующем разделе.

Кроме использования strace, анализ также можно запустить на основе файла compile_commands.json (JSON Compilation Database). Многие системы сборки позволяют экспортировать команды вызовов компилятора, или вы можете воспользоваться для этого утилитой BEAR. Запустить анализ в этом случае можно командой

Следует отметить, что анализатор распознает используемый компилятор по имени его исполняемого файла. Если при проверке вы получаете ошибку «No compilation units found», попробуйте указать имя вашего компилятора через параметр –compiler или –c:

Это может понадобиться при кросс-компиляции и использовании компиляторов с нестандартными именами исполняемых файлов.

Кроме запусков в режиме мониторинга, вы можете интегрировать анализатор в вашу сборочную систему или IDE. Примеры проектов с уже настроенной интеграцией вы можете найти на GitHub в репозитории PVS_Studio:

Работа с отчетами

После проверки проекта анализатор создает закодированный отчет. Для того, чтобы конвертировать его в один из поддерживаемых форматов, следует использовать утилиту plog-converter, которая устанавливается вместе с PVS-Studio.

Утилита поддерживает следующие форматы:

• xml – удобный формат для дополнительной обработки результатов анализа, поддерживается плагином для SonarQube;
• csv – текстовый формат, предназначенный для представления табличных данных;
• errorfile – формат вывода gcc и clang;
• tasklist – формат ошибок, который можно открыть в QtCreator;
• html – отчет html с кратким описанием результатов анализа;
• fullhtml – отчет html с сортировкой результатов анализа по разных параметрам и навигацией по исходному коду.

Для просмотра отчета наиболее удобен формат fullhtml, так как он позволяет перейти на строку исходного кода, в которой возникло предупреждение. Следующая команда позволяет сконвертировать отчет анализатора в этот формат:

После выполнения команды будет создан каталог /path/report_dir, в котором будут лежать файлы отчета.

Обратите внимание на ключ -a. Он позволяет указать, какие именно предупреждения должны попасть в отчет. Это удобно, если есть необходимость отфильтровать вывод анализатора. Приведенная выше команда создаст отчет, который будет содержать только предупреждения из группы general analysis первого и второго уровней достоверности (High и Medium).

По клику в ячейке Location сообщения можно перейти к соответствующей строке кода:

Клик по номеру диагностики в колонке Code откроет документацию с описанием этой диагностики.

Подавление срабатываний анализатора

При проверке кода статическим анализатором возможны ложные срабатывания или просто нежелательные сообщения (шум). PVS-Studio предоставляет механизмы подавления таких предупреждений. Для индивидуального подавления срабатываний, можно применить один из способов, описанных в разделе документации «Подавление ложных предупреждений».

Также при анализе старого кода может возникнуть необходимость массово подавить все сообщения. Как правило, это нужно для того, чтобы проверять только тот код, который добавляется в существующую кодовую базу. Для этого используется параметр suppress утилиты pvs-studio-analyzer.

Массово подавить сообщения в отчете можно следующей командой:

Информация о подавленных сообщениях хранится в файле suppress_base.json, который лежит рядом с проектом. Такие сообщения исключаются из отчета при последующих проверках.

Подробнее этот механизм описан в документации здесь.

Заключение

Это было краткое введение в использование анализатора PVS-Studio под Linux. Надеюсь, оно было полезным и ответило на наиболее часто возникающие вопросы. Более подробно о теме статьи вы можете прочитать в документации здесь.

Если хотите поделиться этой статьей с англоязычной аудиторией, то прошу использовать ссылку на перевод: Yuri Minaev. Getting Started with the PVS-Studio Static Analyzer for C++ Development under Linux.

Источник

Getting Started with the PVS-Studio Static Analyzer for C++ Development under Linux

PVS-Studio supports analyzing projects developed in C, C++, C#, and Java. You can use the analyzer under Windows, Linux, and macOS. This small article will tell you the basics of analyzing C and C++ code in Linux environment.

Installation

There are different ways to install PVS-Studio under Linux, depending on your distro type. The most convenient and preferred method is to use the repository, since it allows auto-updating the analyzer upon releasing new versions. Another option is to use the installation package, which you can get here.

The installation commands differ depending on the Linux distro you are using. For instance, this is how installation from the repository under Debian-based systems looks like:

To install PVS-Studio from the downloadable package, you can use the gdebi utility:

The installation process is described in greater detail in the «Installing and updating PVS-Studio on Linux» documentation section. You can also find information on non-Debian systems there.

Once PVS-Studio is installed, you need to enter license data. Here’s the command for that:

NAME and KEY are the registered user name, and the license key respectively. The optional parameter –o allows you to specify the location, where a license file will be generated. By default, it will be stored in the

If you need a trial key, you can get it at the «Download and evaluate PVS-Studio» page.

Checking your project

Once you get the analyzer installed, you can start checking projects. There are two main ways to do this:

1. Compilation monitoring.
2. Running from build systems directly.

Let’s talk about the first way. To launch the monitoring under Linux, you need the strace utility. PVS-Studio uses it to collect a list and parameters of processes, which were launched during the build.

Use the command below to initiate the build:

Here, make is used, but any other command that you’re running to build your project can be in its place. If needed, you can pass command-line parameters to it in the usual way.

After the build, strace will create a file, which the analyzer will then use to check the source code. To start the analysis, use the command below.

As a result, an encoded log file will be generated, which you can convert to one of supported formats. We’ll talk about working with reports later.

Besides strace, you can base the analysis on the compile_commands.json (JSON Compilation Database) file. Many build systems have built-in means of exporting compilation commands, or you could use the BEAR utility to do this. Here’s the command to launch the analysis in this case:

Note that the analyzer recognizes the compiler, used in the build process, by its executable name. If you get the «No compilation units found» error whilst attempting to analyze your project, try explicitly specifying the name of your compiler via the –compiler or –c command-line key:

You may need this if you’re using cross-compilation, or if your compiler has a non-standard executable name.

Besides monitoring mode, you can integrate the analyzer directly into your build system or IDE. Our official GitHub repository provides example projects where the integration has already been configured:

Working with reports

After checking a project, the analyzer creates an encoded report. To convert it to one of supported formats, you need to use the plog-converter utility, which comes with the PVS-Studio installation.

Here’s a list of supported formats:

• xml-a convenient format for further processing of the results of the analysis, which is supported supported by the plugin for SonarQube;
• csv — file stores tabular data (numbers and text) in plain text;
• errorfile is the output format of the gcc and clang;
• tasklist — an error format that can be opened in QtCreator;
• html — html report with a short description of the analysis results;
• fullhtml — report with sorting of the analysis results according to the different parameters and navigation along the source code.

The fullhtml format is the most convenient one for viewing the report, since it allows jumping to the line of code, corresponding to the warning you’re interested in. The following command allows you to convert the report to this format:

When you launch it, a newly created directory named /path/report_dir will contain all the report files.

Pay attention to the -a parameter. It allows you to specify, which warnings should appear in the resulting report. It is convenient if you need to filter the analyzer’s output. The above command will create a report, which will contain only general analysis messages of the first and second certainty levels (High and Medium).

An example report:

By clicking within a message’s Location cell, you can jump to the corresponding line of code:

By clicking the diagnostic code in the Code column, you can open documentation on this diagnostic.

Suppressing analyzer warnings

When using any static analyzer to check source code, you might get false positives, or simply undesirable noise warnings. PVS-Studio has means of suppressing such messages. To target individual warnings, you can use one of the methods described in the «Suppression of false alarms» documentation article.

Also, when checking old code you might want to suppress all warnings. As a rule, you may need this if you only want to check new code that you add to an existing codebase. To do this, use the suppress parameter of the pvs-studio-analyzer utility.

You can mass-suppress warnings in a report by using this command:

Information on suppressed warnings is stored in a file named suppress_base.json, which is located next to the project. Such messages are excluded from reports on subsequent checks.

This mechanism is described in detail here.

Источник

Как создавался PVS-Studio под Linux

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

Введение

Вообще, консольное ядро анализатора PVS-Studio собрано под Linux довольно давно. Уже около трех лет. Сразу отвечу на вопрос об отсутствии такой версии в общественном доступе — сделать программный продукт, даже на основе уже существующего, это огромная работа и много человеко-часов, куча непредвиденных проблем и нюансов. Тогда мы это только предвидели, поэтому официальная поддержка анализатора для Linux систем не начиналась.

Являясь автором многих статей о проверке проектов, в отличии от моих коллег, я часто черпал вдохновение в проектах из Linux. Эта среда очень богата крупными и интересными проектами с открытым исходным кодом, которые либо очень сложно собрать в Windows, либо вообще невозможно. Именно в рамках таких задач по проверке какого-нибудь открытого проекта до сегодняшнего дня и развивался PVS-Studio для Linux.

Малыми силами портирование кода ядра PVS-Studio на Linux заняло пару месяцев. Замена нескольких обращений к системным функциям и отладка на проекте Chromium дали уже хорошо работающее консольное приложение. Эта версия анализатора была добавлена в регулярные ночные сборки, а также проверялась анализатором Clang Static Analyzer. Периодические проверки открытых проектов и контроль сборки позволили анализатору беспроблемно существовать несколько лет и иногда даже казалось, что этот инструмент уже можно продавать. Но вы ещё не знаете, как мне приходилось проверять проекты на тот момент…

О применении инструментов статического анализа

Прежде чем продолжить рассказ о разработке нашего инструмента, я бы хотел немного рассказать о самой методологии статического анализа. Тем самым, сразу ответив на вопросы в стиле: «Зачем пользоваться сторонними инструментами, если сразу можно писать код без ошибок и делать ревью с коллегами?». К сожалению, такой вопрос довольно часто звучит.

Статический анализ кода позволяет выявлять ошибки и недочёты в исходном коде программ. Независимо от используемых инструментов, это отличная методология контроля качества кода будущих приложений. Если есть возможность, то полезно совмещать разные инструменты статического анализа.

Среди наших читателей, пользователей или слушателей на конференциях встречаются люди, которые считают, что обзора кода с коллегами более чем достаточно для выявления ошибок на раннем этапе написания кода. И кое-что в таких «досмотрах» наверняка удаётся найти. Но всё это время мы говорим об одном и том же. Ведь статический анализ можно рассматривать как автоматизированный процесс обзора кода. Представьте, что статический анализатор — это ещё один ваш коллега. Этакий виртуальный человек-робот, который без устали участвует во всех обзорах кода и указывает на подозрительные места. Разве это не полезно?!

Во многих отраслях производства прибегают к автоматизации с целью исключения так называемого «человеческого фактора». И контроль качества кода — не исключение. Мы не призываем отказываться от ручного code-review, если вы его практикуете. Просто использование статического анализатора поможет выявлять ещё больше ошибок на самом раннем этапе.

Ещё важный момент — программа не устаёт и не ленится. В код вносятся ошибки различного характера. Опечатки? Их очень сложно выделить глазами. Языковые ошибки? Сильно зависят от квалификации проверяющего. Ситуацию усугубляют современные объёмы кода. Многие функции не помещаются целиком даже на больших мониторах. При неполноте контекста бдительность проверяющего уменьшается. Плюс человек уже через 15 минут внимательного чтения кода начинает уставать. И чем дальше, тем сильнее. Отсюда и популярность инструментов автоматического анализа, которая растет с каждым годом.

Что просили пользователи PVS-Studio от версии для Linux?

Наш продукт всегда был интересен людям, так или иначе связанным с разработкой программ. Это Windows пользователи, которые сразу могли попробовать анализатор. Не программисты вообще или программисты других платформ и языков, которые также с интересом следят за нашей активностью. Такое внимание ожидаемо, т.к. многие ошибки являются общими для многих языков программирования.

Пользователи Linux долго и упорно спрашивали про работу анализатора на этой платформе. Вопросы и аргументы можно обобщить следующим образом:

• Утилита командной строки — «Интеграция с IDE не нужна!»
• Инсталлятор не нужен — «Сами все установим!»
• Документация не нужна — «Сами запустим!»

Дальнейший рассказ будет многократно подтверждать несоответствие заявлений пользователей их ожиданиям.

Миф о понимании сборочных скриптов

После общения с людьми из крупных коммерческих проектов выяснилось, что достаточно много разработчиков не знакомы со сборкой проектов и на самом деле такие знания не всегда нужны в полном объёме. Как собрать/отладить свой проект/модуль каждый разработчик знает. Но обычно всё это знание заключается в наборе нескольких магических команд, которые выполняют программисты. Образно говоря, у них есть большая кнопка, на которую достаточно нажать и на выходе они получают собранные модули. Но о том, как всё это работает внутри, они имеют только общее представление. А за сборочными скриптами часто следит специальный человек.

В таких случаях необходим инструмент для проверки проекта без интеграции, как минимум для ознакомления с анализатором.

Linux версия анализатора появились как раз после того, к в Windows мы сделали систему мониторинга компиляторов, которая позволила проверять любые проекты на этой платформе. Как потом выяснилось, там достаточно много серьёзных проектов, которые собираются с помощью компилятора от Microsoft, но при этом не имеют проекта для Visual Studio. Так мы написали статьи о проверке Qt, Firefox, CryEngine5 и даже сотрудничали с Epic Games, исправляя ошибки в их коде. Наше исследование показало, что если знать информацию о компиляторе: директорию запуска, параметры командной строки и переменные окружения, то этой информации достаточно, чтобы позвать препроцессор и выполнить анализ.

Планируя проверять Linux проекты, я сразу понимал, что не разберусь с интеграцией анализатора в каждый конкретный проект, поэтому сделал аналогичную систему мониторинга для ProcFS (/proc/id’s). Брал код из Windows плагина и запускал его в mono для анализа файлов. Несколько лет такой способ использовался для проверки проектов, самые крупные из которых — ядро Linux и FreeBSD. Несмотря на длительное использование такого способа, он ни в коем случае не годится для массового использования. Продукт ещё не готов.

Выбор технологии мониторинга

Приняв решение о необходимости и важности такого функционала, мы начали делать прототипы и выбирать.

(-) Clang scan-build — посмотрев скрипты Clang’a, мы сделали прототип, который аналогичным образом прописывал вызов анализатора в переменные CC/CXX. Мы раньше сталкивались с тем, что таким способом не удаётся проверить некоторые открытые проекты с помощью Clang Static Analyzer. Разобравшись получше в этом способе, мы поняли, что часто в проектах в эти переменные дописывают и флаги компиляции. И при переопределении переменных их не удаётся сохранить. Поэтому мы отказались от этого способа.

(+) strace — утилита выдаёт довольно подробный лог трассировки, в котором большая часть залогированных процессов не относится к компиляции. Также в формате вывода этой утилиты отсутствует так необходимая нам рабочая директория процесса. Но директорию удалось найти, связав дочерние и родительские процессы, а приложение на C++ очень быстро парсит такой файл, запуская анализ найденных файлов параллельно. Так можно проверить проекты с любой сборочной системой и познакомиться с анализатором. Например, недавно мы снова перепроверили Linux Kernel, теперь легко и просто.

(+) JSON Compilation Database — такой формат можно получить для CMake проекта, указав один дополнительный флаг. В нём есть вся нужная информация для анализа без лишних процессов. Поддержали.

(±) LD_PRELOAD — интеграция анализатора через замещение функций. Этот способ не будет работать, если сборка проекта уже осуществляется таким образом. Также есть утилиты, позволяющие получить JSON Compilation Database для не CMake-проектов с помощью LD_PRELOAD (Например, Bear). В них есть небольшое отличие от CMake, но мы их тоже поддержали. И если в проекте нет зависимости от каких-то установленных переменных окружения, то мы тоже сможем проверить проект. Поэтому ±.

Появление регулярных тестов

Существуют разные способы тестирования программного обеспечения. Для тестирования анализатора и диагностик самыми эффективными являются прогоны на большой кодовой базе открытых проектов. Для начала мы выбрали около 30 крупных проектов с открытым исходным кодом. Ранее я упоминал, что собранный анализатор в Linux просуществовал не один год и проекты для статей проверялись регулярно. Казалось, что всё хорошо работает. Но только начав полноценное тестирование, мы увидели полную картину недоработки анализатора. Перед началом анализа необходимо выполнить разбор кода, чтобы найти нужные конструкции. Несмотря на незначительное влияние неразборного кода на качество анализа, всё же ситуация неприятная. Нестандартные расширения есть во всех компиляторах, но MS Visual C/C++ мы их давно поддерживаем, а c GCC нам пришлось начать эту борьбу почти с самого начала. Почему почти? В Windows мы давно поддержали работу с GCC (MinGW), но он там не так сильно распространён, поэтому ни у нас, ни у пользователей проблем не возникало.

Расширения компиляторов

В данном разделе речь пойдёт о коде, который вы, как я надеюсь, больше нигде не увидите: коде, использующем расширения GCC. Казалось бы, зачем они могут нам понадобиться? В большинстве кроссплатформенных проектов их вряд ли станут использовать. Во-первых, как показывает практика, их используют. Разрабатывая систему тестирования проектов под Linux, мы встречали такой код. Но основная проблема возникает при разборе кода стандартной библиотеки: уж там расширения используются во всю силу. В препроцессированных файлах из своего проекта никогда нельзя быть уверенным: ради оптимизации привычная вам функция memset может оказаться макросом, состоящим из statement expression. Но обо всём по порядку. Какие новые конструкции мы встретили, проверяя проекты под Linux?

Одним из первых встреченных расширений стали designated initializers. С помощью них можно проинициализировать массив в произвольном порядке. Особенно это удобно, если индексируется он по enum: мы в явном виде указываем индекс, повышая тем самым читабельность и уменьшая вероятность ошибиться при его модификации в дальнейшем. Выглядит очень красиво и просто:

Ради спортивного интереса немного усложним пример:

То есть, в качестве инициализатора в данной конструкции может идти любая последовательность индексаций и обращений к членам структуры. В качестве индекса может быть также указан диапазон:

Небольшое, но очень полезное с точки зрения безопасности расширение GCC связано с нулевым указателем. О проблеме использования NULL было сказано уже много слов, не буду повторяться. Для GCC ситуация немного лучше, потому что NULL в C++ объявлен как __null. Таким образом, GCC уберегает нас от подобных выстрелов в ногу:

При компиляции получаем ошибку:

В GCC есть возможность задавать атрибуты __attribute__(()). Есть целый список атрибутов для функций, переменных и типов, с помощью которых можно управлять линковкой, выравниванием, оптимизациями и многими другими вещами. Одним из интересных атрибутов является transparent_union. Если сделать такой union параметром функции, то в качестве аргумента можно передавать не только сам union, но и указатели из этого перечисления. Вот такой код будет корректен:

Примером, который использует transparent_union, может послужить функция wait: она может принимать как int*, так и union wait*. Сделано это в угоду совместимости с POSIX и 4.1BSD.

Про вложенные функции в GCC вы наверняка слышали. В них можно использовать переменные, объявленные до функции. Ещё вложенную функцию можно передавать по указателю (хотя и не стоит, по понятным причинам, вызывать её по этому указателю после завершения работы основной функции).

Но знали ли вы, что из такой функции можно сделать goto в «функцию-родителя»? Особенно эффектно это смотрится в сочетании с передачей такой функции в другую.

На практике правда такой код может привести к крайне печальным последствиям: exception safety — достаточно сложная тема даже для C++ с RAII, не говоря уж о C. Поэтому лучше так не делать.

К слову о goto. В GCC метки можно сохранять в указатели и переходить по ним. А если записать их в массив, получится таблица переходов:

А это небольшое расширение Clang. С этим компилятором PVS-Studio работать умеет уже давно, тем не менее, даже сейчас мы не перестаём удивляться новым конструкциям, появляющимся в языке и компиляторах. Вот одна из них:

При такой записи компилятор проверяет, что переданный массив имеет 10 или более элементов и выдаёт предупреждение, если это не так:

Закрытое тестирование Beta версии. Волна 1

Подготовив стабильную версию анализатора, документацию и несколько способов проверки проектов без интеграции, мы начали закрытое тестирование.

Когда мы начали выдавать анализатор первым тестерам, выяснилось, что предоставлять анализатор исполняемым файлом недостаточно. Мы получали отзывы от «У вас отличный продукт, мы нашли кучу ошибок» до «Я не доверяю вашему приложению и не буду его устанавливать в /usr/bin!». К сожалению, последних было больше. Таким образом, аргументы форумчан о возможности самостоятельной работы с исполняемым файлом были преувеличены. В таком виде работать с анализатором могут или хотят не все. Необходимо воспользоваться какими-нибудь общепринятыми способами распространения ПО в Linux.

Закрытое тестирование Beta версии. Волна 2

Получив первые отзывы, мы остановили тестирование и окунулись в напряжённую работу почти на 2 недели. Тестирование на чужом коде выявило ещё больше проблем с компиляторами. Т.к. на базе GCC создаются компиляторы и кросс-компиляторы под различные платформы, то наш анализатор начали использовать для проверки чего угодно, даже программного обеспечения разных железяк. В принципе анализатор справлялся со своими обязанностями, и мы получали благодарственные отзывы, но некоторые фрагменты кода анализатор пропускал из-за расширений, которые нам приходилось поддерживать.

Ложные срабатывания присущи любому статическому анализатору, но в Linux их количество у нас немного выросло. Поэтому мы занялисьдоработкой диагностик под новую платформу и компиляторы.

Большой доработкой было создание Deb/Rpm пакетов. После их появления, недовольства по установке PVS-Studio отпали. Был, наверное, всего один человек, которого возмутила установка пакета с использованием sudo. Хотя таким образом ставится почти весь софт.

Закрытое тестирование Beta версии. Волна 3

Мы также сделали небольшой перерыв на доработку и внесли следующие изменения:

Отказ от конфигурационных файлов для быстрой проверки — после введения Deb/Rpm пакетов первое место заняла проблема с заполнением конфигурационного файла для анализатора. Пришлось доработать режим быстрой проверки проектов без конфигурационного файла всего с двумя обязательными параметрами: путь к лицензионному файлу и путь к отчёту анализатора. Возможность расширенной настройки этого режима осталась.

Улучшена работа с логом утилиты strace — изначально лог утилиты strace обрабатывался скриптом на языке Perl, на котором был сделан прототип. Скрипт медленно работал и плохо распараллеливал анализ. После переписывания этого функционала на С++ обработка файла ускорилось, также стало легче поддерживать весь код на одном языке программирования.

Доработка Deb/Rpm пакетов — т.к. для работы режима быстрой проверки нужна утилита strace и в первые пакеты входили Perl/Python скрипты, то мы не сразу правильно прописали все зависимости, а позже вовсе отказались от скриптов. Позже несколько человек написали про предупреждения при установке анализатора через графические менеджеры, и мы их быстро устранили. Тут хочется отметить пользу от способа тестирования, который мы для себя настроили: в Docker разворачиваются несколько десятков дистрибутивов Linux и в них устанавливаются собранные пакеты. Возможность запуска установленных программ тоже проверялась. Такое тестирование позволило нам оперативно вносить новые изменения в пакеты и тестировать их.

Другие доработки по анализатору и документации. Все наши наработки мы отражали в документации. Ну а работа по доработке анализатора не прекращается никогда: это новые диагностики и улучшение существующих.

Закрытое тестирование Beta версии. Волна 4 (Release Candidate)

В последней волне рассылки анализатора у пользователей уже отсутствуют проблемы с установкой, запуском и настройкой анализатора. Мы получаем благодарственные отзывы, примеры найденных реальных ошибок и примеры ложных срабатываний.

Также пользователи стали больше интересоваться расширенными настройками анализатора. Поэтому мы начали дорабатывать документацию на предмет, как интегрировать анализатор в Makefile/CMake/QMake/QtCreator/CLion. Как это выглядит, я покажу далее.

Проработанные способы интеграции

Интеграция в Makefile/Makefile.am

Несмотря на удобство проверки проекта без интеграции, непосредственно у прямой интеграции в сборочную систему есть ряд преимуществ:

• Тонкая настройка анализатора;
• Инкрементальный анализ;
• Распараллеливание анализа на уровне сборочной системы;
• Другие преимущества от сборочной системы.

Когда анализатор вызывается там же, где и компилятор, то у анализатора правильно настроено окружение, рабочая директория и все параметры. В этом случае выполняются все условия для правильного и качественного анализа.

Примерно так выглядит интеграция в Makefile:

Интеграция в CMake/CLion

Изучив интеграцию анализатора в CMake, стало возможным использование PVS-Studio в CLion. Можно получать как файл с отчётом анализатора, так и выводить предупреждения в IDE для просмотра проблемных мест.

Интеграция в CMake/QtCreator

Для работы с CMake проектами в QtCreator точно также можно сохранять отчёт или сразу просматривать предупреждения в IDE. В отличии от CLine, QtCreator умеет открывать для просмотра отчёты, сохранённые в формате TaskList.

Интеграция в QMake/QtCreator

Для QMake проектов мы тоже предусмотрели способ простой интеграции:

Заключение

К чему мы пришли за время разработки:

1. Анализатор легко установить из пакета или репозитория;
2. С анализатором легко познакомиться, выполнив проверку без интеграции анализатора в сборочную систему;
3. Для регулярного использования анализатора можно настроить инкрементальный анализ на машине каждого разработчика;
4. Настройка полной проверки на build-сервере;
5. Интеграция с популярными IDE.

Такой инструмент уже можно показывать людям, что мы и сделали.

Скачать и попробовать анализатор можно по ссылке. Следите за нашими новостями и присылайте проекты для проверки, теперь и в Linux!

Если хотите поделиться этой статьей с англоязычной аудиторией, то прошу использовать ссылку на перевод: Svyatoslav Razmyslov: The Development History of PVS-Studio for Linux .

Источник