Мы используем куки, чтобы пользоваться сайтом было удобно.
Хорошо
to the top

Вебинар: Хороший тимлид — не друг и не надсмотрщик. Как найти баланс через 1-to-1 - 28.05

>
>
>
PVS-Studio в CMake: теперь официально!

PVS-Studio в CMake: теперь официально!

18 Май 2026

Если у вас кроссплатформенный проект на C или C++, то, как правило, вы не завязываетесь на одну систему сборки, а используете генератор сценариев для сборочных систем. Самый распространённый из них, CMake, недавно получил официальную интеграцию со статическим анализатором PVS-Studio для этих языков.

CMake — визитная карточка Kitware для разработчиков программного обеспечения. Это проект с большой историей и возрастом почти с саму компанию. Его первая версия вышла в 2000 году, спустя примерно два года со дня основания Kitware.

Со временем все разработки Kitware (например, библиотека Visualization Toolkit и созданный на её основе движок ParaView для работы с симуляциями протекающих процессов) стали использовать CMake для описания структуры проекта и его сборки. Вслед за ними подключились другие крупные проекты СПО: KDE, LLVM, Qt в разное время полностью отказались от GNU Autoconf в его пользу. Анализатор PVS-Studio для C и C++ полностью перешёл на CMake в начале 2020 года.

PVS-Studio может анализировать проекты независимо от системы сборки: на Windows анализатор перехватывает вызовы компилятора и его команды запуска. Для GNU/Linux систем доступна трассировка компиляции.

Как это работает

Начиная с версии 4.3, в CMake стал возможен запуск PVS-Studio одновременно со сборкой C или C++ проекта. Срабатывания анализатора будут отображаться вместе с сообщениями и предупреждениями компилятора.

Рисунок 1. Начало журнала сборки компонента libcrypto из LibreSSL 4.3.1 с одновременным анализом средствами PVS-Studio

Процесс настройки статического анализатора PVS-Studio практически не отличается от других поддерживаемых в CMake решений: достаточно объявить директиву CMAKE_<LANG>_PVS_STUDIO и после неё перечислить параметры, как если бы вы просто запустили CompilerCommandsAnalyzer в Windows или pvs-studio-analyzer в *nix-системах. <LANG> может принимать значения C и CXX.

set(CMAKE_C_PVS_STUDIO CompilerCommandsAnalyzer analyze -a GA)
set(CMAKE_CXX_PVS_STUDIO CompilerCommandsAnalyzer analyze -a GA)

Эту директиву можно разместить на любом подходящем для вас уровне в CMakeLists.txt, регулируя таким образом количество кода, которое проверяет анализатор.

Мы проверяли исходный код CMake 4.1 в августе 2025 года. Анализатор PVS-Studio для C и C++ нашёл в нём много интересного.

Анализ через встроенную интеграцию накладывает ограничение на взаимодействие с результатами анализа: отчёт PVS-Studio не сохраняется, так как файлы исходного кода анализируются индивидуально. Из-за этого недоступна конвертация отчёта через plog-converter, но вы можете агрегировать срабатывания анализатора в CDash — системе контроля результатов прохождения тестов, также разработанной Kitware. Разработчики из команды CMake так и сделали — здесь можно посмотреть на результат работы такой интеграции.

Применяем на практике

Рассмотрим процесс анализа на примере криптографической библиотеки LibreSSL — хардфорка OpenSSL, направленного на улучшение качества кодовой базы, её безопасности и поддержки. Примеры команд запуска будут написаны под Windows.

Открываем корневой файл CMakeLists.txt, добавляем строку:

set(CMAKE_C_PVS_STUDIO CompilerCommandsAnalyzer analyze -a "GA\;OP")

Далее генерируем файлы для системы сборки Ninja:

cmake -B build -G Ninja

После этого запускаем любую цель для сборки, например, libtls — новый вариант библиотеки libssl для TLS-соединений:

cd build
ninja tls

Запускается сборка, запускается и анализ.

Рисунок 2. Начало журнала сборки компонента libtls из LibreSSL 4.3.1 с одновременным анализом средствами PVS-Studio

Срабатывания анализатора PVS-Studio отображаются в удобном для чтения "в потоке" формате: путь до файла с позицией в коде, номер диагностического правила и его описание. Давайте рассмотрим пару срабатываний из криптографического ядра libcrypto, используемого в libtls:

Надувательство

void
BF_ecb_encrypt(const unsigned char *in, unsigned char *out,
    const BF_KEY *key, int encrypt)
{
    BF_LONG l, d[2];

    n2l(in, l);
    d[0] = l;
    n2l(in, l);
    d[1] = l;
    if (encrypt)
        BF_encrypt(d, key);
    else
        BF_decrypt(d, key);
    l = d[0];
    l2n(l, out);
    l = d[1];
    l2n(l, out);
    l = d[0] = d[1] = 0;              // <=
}

Предупреждение PVS-Studio: V1001 The 'l' variable is assigned but is not used by the end of the function. blowfish.c 587

Перед нами простой и незамысловатый алгоритм Blowfish. Конкретно здесь быстрая очистка буфера данных на шифровку или дешифровку в зависимости от значения encrypt. Но затирание не произойдёт, если приложение было скомпилировано с оптимизацией и 12 байт, из которых 8 являются блоком данных, останутся висеть в памяти.

Вы повторяетесь. Вы повторяетесь.

Для чтения информации из сертификатов X.509 и родственных ему нужен парсер Abstract Syntax Notation Once (ASN.1).

Предупреждение PVS-Studio: V501 There are identical sub-expressions '(c == ' ')' to the left and to the right of the '||' operator. a_print.c 77:

int
ASN1_PRINTABLE_type(const unsigned char *s, int len)
{
  int c;
  ....
  while (len-- > 0 && *s != '\0') {
    c= *(s++);
    if (!(((c >= 'a') && (c <= 'z')) ||
        ((c >= 'A') && (c <= 'Z')) ||
        (c == ' ') ||                   // <=
        ((c >= '0') && (c <= '9')) ||
        (c == ' ') || (c == '\'') ||    // <=
        (c == '(') || (c == ')') ||
        (c == '+') || (c == ',') ||
        (c == '-') || (c == '.') ||
        (c == '/') || (c == ':') ||
        (c == '=') || (c == '?')))
      ia5 = 1;
    if (c & 0x80)
      t61 = 1;
  }
  ....
}

Немного "растянем", расположив условия в if в один столбец:

if (!(
       ((c >= 'a') && (c <= 'z'))
    || ((c >= 'A') && (c <= 'Z'))
    || (c == ' ')                   // <=
    || ((c >= '0') && (c <= '9'))
    || (c == ' ')                   // <=
    || (c == '\'')
    ....
))

Вот и запрятавшийся в водорослях повтор проверки на пробел. Полагаем, что это чистая случайность :)

Убрать его можно в любой понравившейся вам части условия без потери функциональности:

if (!(((c >= 'a') && (c <= 'z')) |
    ((c >= 'A') && (c <= 'Z')) ||
    ((c >= '0') && (c <= '9')) ||
    (c == ' ') || (c == '\'') ||
    (c == '(') || (c == ')') ||
    (c == '+') || (c == ',') ||
    (c == '-') || (c == '.') ||
    (c == '/') || (c == ':') ||
    (c == '=') || (c == '?')))

Бывают и более сложные случаи повторяющихся проверок в условии. Чтобы их не допускать, можно применить "табличное" форматирование кода.

Останутся ли старые способы анализа?

Привычные способы анализа CMake-проектов через compile_commands.json и CMake-модуль никуда не пропали, ими по-прежнему можно пользоваться. Все возможные методы описаны в нашей документации. Поддерживать код чистым от багов стало ещё проще, и мы надеемся, что интегрировать статический анализ в процесс разработки будет так же легко! Если вы хотите попробовать новую интеграцию прямо сейчас, можно бесплатно запросить триальную лицензию.

Подписаться на рассылку
Хотите раз в месяц получать от нас подборку вышедших в этот период самых интересных статей и новостей? Подписывайтесь!
Популярные статьи по теме

Комментарии (0)

Следующие комментарии next comments
close comment form