Unicorn with delicious cookie
Мы используем куки, чтобы пользоваться сайтом было удобно.
Хорошо
to the top
>
>
Кроссплатформенная проверка C и C++...
menu mobile close menu
Проверка проектов
Дополнительная информация
toggle menu Оглавление

Кроссплатформенная проверка C и C++ проектов в PVS-Studio

10 Июн 2025

Введение

PVS-Studio поддерживает проверку кроссплатформенных проектов на C и С++ вне зависимости от используемой сборочной системы. Для этого используется специальная утилита для Linux и macOS — pvs-studio-analyzer и для Windows — CompilerCommandsAnalyzer.exe. Все примеры запуска, описанные в этой документации, будут использовать имя pvs-studio-analyzer.

Подробную информацию по проверке проектов Visual Studio вы найдёте в отдельной инструкции:

На Windows вы также можете использовать сервер мониторинга компиляции.

Примечание. Утилиты pvs-studio-analyzer и CompilerCommandsAnalyzer.exe являются одним и тем же кроссплатформенным приложением и имеют незначительные отличия. Платформо-зависимые особенности будут описаны в данном документе. Все примеры запуска pvs-studio-analyzer являются кроссплатформенными, если в описании к ним не говорится обратное.

Активация лицензии

Для работы анализатора активируйте лицензию одним из способов, предложенных в документации.

Если у вас нет лицензии, вы можете запросить её через форму обратной связи.

Подготовка к анализу проекта

Для запуска анализа проекта утилите pvs-studio-analyzer необходимо иметь представление о параметрах запуска компиляции для каждой единицы трансляции. Эти параметры могут быть получены из JSON Compilation Database (compile_commands.json) либо из файла трассировки сборки.

Важно. Для анализа проект должен успешно собираться.

Использование базы данных компиляции (Windows, Linux, macOS)

Многие сборочные системы (CMake, Ninja и другие) позволяют сгенерировать файл compile_commands.json. Для сборочных систем, не предусматривающих получение compile_commands.json напрямую, существуют разные утилиты, позволяющие сгенерировать его, например Bear, Text Toolkit, intercept-build и другие.

Процесс генерации JSON Compilation Database и анализа подробно описан в документации.

Создание файла трассировки компиляции (только Linux)

Если у вас нет возможности сгенерировать compile_commands.json для своего проекта, воспользуйтесь режимом трассировки компиляции. Данный режим работает только на Linux и использует утилиту strace для перехвата вызовов компилятора.

Примечание. Для мониторинга компиляции на Windows воспользуйтесь сервером мониторинга компиляции CLMonitor.

Важно. Для трассировки компиляции в системе должен быть установлен strace версии 4.7 и выше, а также включён системный вызов PTRACE. Перед запуском трассировки убедитесь, что в сборочной директории нет артефактов предыдущей сборки. Иначе сборочная система может пропустить вызовы компилятора для неизменённых файлов, если она использует инкрементальный режим сборки. Во многих дистрибутивах PTRACE включён по умолчанию, однако возможны исключения. Для включения PTRACE измените значение параметра kernel.yama.ptrace_scope в файле /etc/sysctl.d/10-ptrace.conf на 1.

Результат трассировки по умолчанию записывается в файл strace_out в текущей директории. При необходимости можно задать произвольный путь для сохранения трассировки с помощью флага -o. Анализатор использует файл strace_out для получения параметров запуска компилятора.

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

pvs-studio-analyzer trace [-o <FILE>] -- build_command

build_command — команда, используемая для сборки проекта.

Пример:

pvs-studio-analyzer trace -- cmake build .

Анализ проекта

После формирования JSON Compilation Database или файла трассировки компиляции можно перейти к анализу проекта.

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

pvs-studio-analyzer analyze [-o /path/to/PVS-Studio.log] \
                            [-e /path/to/exclude-path]... \
                            [-j <N>]

Далее приведено описание всех флагов запуска анализа.

Описание общих флагов

  • ‑‑cfg [FILE] (-c [FILE]) — задаёт файл конфигурации *.cfg, в который можно поместить некоторые параметры запуска анализатора (например, exclude-path, lic-file и др.). В следующем разделе будет дано описание настроек файла конфигурации. Вы можете использовать файл конфигурации, чтобы вынести туда общие параметры проверки различных проектов.
  • ‑‑lic-file [FILE] (-l [FILE]) — задаёт путь до файла с лицензией. Для данного параметра есть соответствующая настройка в файле конфигурации.
  • ‑‑threads [N] (-j [N]) — задаёт число потоков для распараллеливания анализа.
  • ‑‑output-file [FILE] (-o [FILE]) — задаёт имя файла, в который будет записан отчёт анализатора. По умолчанию, если данный флаг не указан, отчёт будет записан в файл PVS-Studio.log в текущей директории. Вы можете задать данный параметр в файле конфигурации (*.cfg).
  • ‑‑exclude-path [DIR] (-e [DIR]) — задаёт путь, по которому следует исключить файлы из анализа. Вы можете задать абсолютный или относительный путь. Также можно использовать шаблоны (glob) для исключения набора файлов. Если есть несколько директорий, которые нужно исключить из проверки, добавьте каждую через данный флаг или пропишите их в файле конфигурации.
  • ‑‑analysis-paths [MODE=PATH|GLOB] — определяет поведение анализа на указанных путях. Доступны следующие режимы:
    • skip-analysis — задаёт директорию, файлы из которой не нужно проверять. Обычно это директории системных файлов или подключаемых библиотек. Поведение аналогично флагу ‑‑exclude-path.
    • skip-settings — игнорирует настройки, расположенные в исходных файлах и файлах .pvsconfig по указанному пути.
    • isolate-settings — задаёт директорию, для которой следует изолировать настройки. При использовании данного режима файлы конфигурации правил .pvsconfig из родительских директорий не будут применяться для единиц трансляции в указанной директории и её поддиректориях. Поддерживаются абсолютные и относительные пути. Относительные пути раскрываются через текущую директорию. Для этого режима нельзя использовать шаблоны glob.
    • skip — игнорирует настройки, расположенные в исходных файлах и файлах .pvsconfig по указанному пути. Также будут отфильтрованы предупреждения, сгенерированные для файлов исходного кода по указанному пути или маске.
  • ‑‑analysis-mode [MODE] (-a [MODE]) — задаёт группу предупреждений, которые будут активированы при анализе проекта.
    • 64 — группа диагностик, позволяющих выявлять 64-битные ошибки.
    • GA — группа диагностик общего назначения.
    • OP — диагностики микро-оптимизаций.
    • CS — группа диагностик, добавленных по просьбе пользователей.
    • MISRA — группа диагностик, предназначенных для проверки кода на соответствие стандартам MISRA.
    • AUTOSAR — группа диагностик, предназначенных для проверки кода на соответствие стандартам AUTOSAR.
    • OWASP — группа диагностик, предназначенных для проверки кода на соответствие стандартам OWASP.

Подробнее про MISRA, AUTOSAR и OWASP можно прочитать в документации.

Если вы хотите задать несколько групп предупреждений, то следует разделить их через символ ; или +. Например: GA;OP;64 или GA+OP+64. Вы можете не указывать кавычки, если используете в качестве разделителя +. Если вы используете в качестве разделителя символ ;, то следует обернуть выражение в кавычки или экранировать каждый ;, т. к. в командной оболочке он обычно обозначает разделитель команд.

По умолчанию используется группа GA.

Также вы можете задать данный параметр в файле конфигурации (*.cfg).

  • ‑‑sourcetree-root [DIR] (-r [DIR]) — указывает, что в отчёте следует заменить корневую часть пути (DIR) на специальный символ. По умолчанию при генерации предупреждений PVS-Studio формирует абсолютные пути до файлов, на которые анализатор выдал срабатывания. С помощью данной настройки можно задать корневую часть пути, которую анализатор будет автоматически подменять на специальный маркер. Замена произойдет, если путь до файла начинается с заданной корневой части ([DIR]). В дальнейшем отчёт с относительными путями можно использовать для просмотра результатов анализа в окружении с отличающимся расположением исходных файлов.
  • ‑‑project-root — задаёт путь до корневой директории проекта. Можно указать абсолютный или относительный путь. Относительный путь будет раскрыт через текущую директорию. Если флаг не указан, то текущая директория будет считаться корнем проекта.
  • ‑‑apply-pvs-configs — флаг включает режим поиска и применения файлов конфигурации правил (.pvsconfig) для каждой единицы трансляции. Файлы конфигурации правил ищутся в директории единицы трансляции и всех родительских директориях (вплоть до корня проекта). Для работы этого режима требуется указать корневую директорию проекта через флаг ‑‑project-root.
  • ‑‑disableLicenseExpirationCheck — флаг устанавливает нулевой код возврата, если срок действия лицензии скоро истечёт. Данный флаг следует использовать, если вы встраиваете анализатор в системы непрерывной интеграции (Travis CI, CircleCI, GitLab CI/CD) или автоматизируете проверку коммитов и Pull Requests и срок действия вашей лицензии скоро закончится (осталось менее 30 дней).

Примечание. Если после обновления лицензии забыть убрать этот флаг, то pvs-studio-analyzer заменит возможный нулевой код возврата кодом 6.

  • ‑‑file [FILE] (-f [FILE]) — задаёт путь до файла трассировки компиляции или JSON Compilation Database. По умолчанию, если этот флаг не указан, PVS-Studio ищет файл strace_out или compile_commands.json в текущей директории. Утилита pvs-studio-analyzer выбирает в приоритете файл compile_commands.json и лишь затем strace_out. Если вы используете JSON Compilation DB, то обязательно указывайте расширение файла .json, иначе он будет трактоваться как файл трассировки. Данный флаг следует задавать, если файл трассировки компиляции или JSON Compilation Database сохранён по нестандартному пути.
  • ‑‑quiet — скрывает прогресс анализа.
  • ‑‑preprocessor [NAME] — задаёт тип препроцессора, который анализатор будет ожидать при разборе препроцессированных файлов (*.PVS-Studio.i). Возможные значения:
    • visualcpp,
    • clang,
    • gcc,
    • bcc,
    • bcc_clang64,
    • iar,
    • keil5,
    • keil5_gnu,
    • c6000.

Во время работы препроцессора выполняется раскрытие макросов и подстановка содержимого файлов, включенных через #include, в результирующий препроцессированный файл. Для корректной навигации компилятора и различных утилит (в том числе и PVS-Studio) по такому файлу препроцессор вставляет специальные #line директивы. Они указывают на файл, содержимое которого было вставлено в данное место.

PVS-Studio нужно знать тип препроцессора для корректной обработки директив #line, специфичных для разных компиляторов.

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

Параметр можно задать в файле конфигурации (*.cfg).

  • ‑‑platform [NAME] — позволяет задать целевую платформу, под которую производится компиляция проекта.

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

  • Windows: win32, x64, Itanium, arm;
  • Linux: linux32, linux64, Itanium, arm;
  • macOS: macOS;
  • Embedded: pic8, tms (Texas instruments).

Информация о платформе нужна анализатору для корректного вывода модели данных.

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

Также параметр может быть задан в файле конфигурации.

  • ‑‑ignore-ccache — включает анализ всех исходных файлов, независимо от состояния ccache. Если в вашем проекте для ускорения сборки используется обёртка над вызовом компилятора (ccache), то анализ не найдёт файлы компиляции. Этот флаг позволяет опустить вызов ccache и обработать обёрнутую в него команду компилятора.
  • ‑‑incremental (-i) — включает инкрементальный анализ проекта.
  • ‑‑source-files [FILE] (-S [FILE]) — задаёт список исходных файлов для режима проверки списка файлов. Он представляет собой текстовый файл, где путь до каждого файла исходного кода расположен на новой строке. Допустимо использовать абсолютные и относительные пути. Относительные пути следует указывать относительно директории, из которой вы хотите запускать анализ. Такой подход удобно использовать при анализе коммитов и pull/merge request.
  • ‑‑regenerate-depend-info [OPTION] — обновляет информацию о зависимостях компиляции для каждого исходного файла. Информация о зависимостях хранится в файле depend_info.json. Флаг поддерживает следующие режимы:
    • run-analysis — обновляет информацию о зависимостях и запускает анализ,
    • skip-analysis — обновляет информацию о зависимостях без запуска анализа.

Файл зависимостей нужен анализатору для корректной проверки списков файлов и для инкрементального анализа. Подробнее об этом можно прочитать в документации.

  • ‑‑suppress-file [FILE] (-s [FILE]) — задаёт путь до файла с подавленными предупреждениями. Предупреждения, попавшие в этот файл, игнорируются при формировании отчёта анализатора. Подробнее об этом можно узнать в документации. По умолчанию файл подавления имеет имя suppress_file.suppress.json.
  • ‑‑analyze-specified-system-paths — включает в анализ файлы из пользовательских системных директорий, которые указаны через флаги компиляции: isystem, isysroot, system_include_dir и т. д.
  • ‑‑compiler [COMPILER_NAME[=COMPILER_TYPE]] (-C [COMPILER_NAME[=COMPILER_TYPE]]) — задает имя и тип компилятора. Данный флаг следует использовать, когда PVS-Studio не может распознать вызовы компилятора (при анализе по файлу трассировки) или запускает компилятор с неправильными флагами препроцессирования, так как вычисляет неверный тип компилятора.
  • COMPILER_NAME — фильтрует команды компилятора при разборе файла трассировки (strace_out).
  • COMPILER_TYPE — задаёт тип компилятора, что позволяет анализатору правильно запустить команду препроцессирования файла. Возможные значения:
    • gcc,
    • clang,
    • keil5,
    • keil5gnu,
    • keil6,
    • tiarmcgt,
    • cl,
    • clangcl,
    • gccarm,
    • iararm_v7_orolder,
    • iararm,
    • qcc,
    • xc8.

Если тип компилятора не указан, анализатор попытаться вывести его по имени или информации о версии. Если это не удастся, он будет считать, что используется gcc на Linux и macOS или cl на Windows.

Например, следующая команда указывает анализатору, что в файле strace_out есть неизвестный ему компилятор с именем CustomCompiler, который следует воспринимать как GCC:

pvs-studio-analyzer analyzer -f /path/to/strace_out \
                             -C CustomCompiler=gcc
  • ‑‑env [VAR=VALUE] (-E [VAR=VALUE]) — задаёт переменную окружения, с которой будет производиться препроцессирование.
  • ‑‑rules-config [FILE] (-R [FILE]) — задаёт файл конфигурации диагностик (*.pvsconfig). Подробнее о конфигурации диагностик можно узнать в документации.
  • ‑‑intermodular — включает режим межмодульного анализа. В этом режиме анализатор выполняет более глубокий анализ кода, но тратит на это больше времени.
  • ‑‑security-related-issues — предупреждения, относящиеся к потенциальным проблемам безопасности и классифицируемые согласно ГОСТ Р 71207-2024, будут выделены дополнительной маркировкой в поле SAST в результатах анализа.
  • ‑‑misra-c-version — задает стандарт MISRA C. Поддерживаемые стандарты MISRA C: 2012, 2023.

Использование файла конфигурации

Файл конфигурации позволяет задать общие параметры запуска анализатора.

Для проекта можно создать отдельный файл конфигурации со специфическими параметрами.

Параметры записываются как пара ключ=значение. Вы можете использовать символ # для комментирования строк.

Возможные значения в конфигурационном файле:

  • exclude-path — задаёт путь (абсолютный или относительный) до файлов или директорий, которые должны быть исключены из анализа. Относительный путь следует указывать относительно директории, содержащей файл конфигурации. Также для указания пути можно использовать шаблоны командных оболочек glob.
  • analysis-paths — определяет поведение анализа на указанных путях. Доступны следующие режимы:
    • skip-analysis — задаёт директорию, файлы из которой не нужно проверять. Обычно это директории системных файлов или подключаемых библиотек;
    • skip-settings — игнорирует настройки, расположенные в исходных файлах и файлах .pvsconfig по указанному пути;
    • isolate-settings — задаёт директорию, для которой следует изолировать настройки. При использовании данного режима файлы конфигурации правил .pvsconfig из родительских директорий не будут применяться для единиц трансляции в указанной директории и её поддиректориях. Поддерживаются абсолютные и относительные пути. Относительные пути раскрываются через текущая директория. Для этого режима нельзя использовать шаблоны glob;
    • skip — игнорирует настройки, расположенные в исходных файлах и файлах .pvsconfig по указанному пути. Также фильтруются предупреждения, сгенерированные для файлов исходного кода по указанному пути или маске.
  • timeout — задаёт время (в секундах), по истечении которого будет прерван анализ единицы трансляции. По умолчанию на анализ одного файла отводится 10 минут (600 секунд). Если передать в качестве значения 0, то ограничение на время будет снято. Однако учтите, что снятие временного ограничения может привести к зависанию анализа.
  • platform — задаёт используемую платформу. Возможные варианты:
    • win32,
    • x64,
    • Itanium,
    • linux32,
    • linux64,
    • macOS,
    • pic8,
    • tms.
  • preprocessor — задаёт используемый препроцессор. Возможные варианты:
    • visualcpp,
    • clang,
    • gcc,
    • bcc,
    • bcc_clang64,
    • iar,
    • keil5,
    • keil5_gnu,
    • c6000.
  • lic-file — задаёт абсолютный или относительный путь до файла лицензии. Путь может быть задан относительно директории, содержащей файл конфигурации.
  • analysis-mode — задаёт тип выводимых предупреждений, который представляет собой битовую маску. С помощью побитового ИЛИ можно задать несколько групп диагностик, которые будут использованы при анализе. Возможные значения:
  • output-file — полный или относительный путь к файлу, в который следует записать отчёт работы анализатора. По умолчанию отчёт будет записан в файл PVS-Studio.log. Относительный путь следует указывать относительно директории, из которой будет произведен запуск анализа. При распараллеливании анализа все процессы ядра PVS-Studio записывают предупреждения в один файл. Следовательно, этот файл будет заблокирован пока последний процесс не запишет в него информацию.
  • funsigned-char — задаёт знаковость типа char. Если true — анализатор трактует char как unsigned char, если false — как знаковый char.
  • rules-config — задаёт путь до файла конфигурации диагностик (*.pvsconfig). Путь может быть задан относительно директории, содержащей файл конфигурации.
  • no-noise — позволяет исключить из отчёта все срабатывания 3-го уровня достоверности. При значении true срабатывания с низким уровнем достоверности не попадут в отчёт анализатора. Значение по умолчанию: false.
  • errors-off — задаёт список выключенных диагностических правил. Список задаётся через пробел или запятую: V1024 V591 или V1024, V591. Диагностические правила, перечисленные в этом списке, не будут применены во время анализа.
  • analyzer-errors — задаёт список включённых диагностических правил. Список может быть задан через пробел или через запятую: V1024 V591 или V1024, V591. Во время анализа будут использованы только те диагностические правила, которые перечислены в этом списке.

Примечание. Список выключенных диагностических правил, заданный через errors-off, имеет больший приоритет, чем список включённых.

Например, зададим основные параметры запуска PVS-Studio в файле конфигурации и запустим анализ проекта, передав анализатору файл *.cfg.

Файл MyProject.cfg:

lic-file=~/.config/PVS-Studio/PVS-Studio.lic
exclude-path=*/tests/*
exclude-path=*/lib/*
exclude-path=*/third-party/*
platform=linux64
preprocessor=clang
analysis-mode=4

Далее происходит запуск анализа. Предполагается, что в текущей директории есть strace_out или compile_commands.json:

pvs-studio-analyzer analyze --cfg ./MyProject.cfg \
                            -o ~/MyProject/MyProject.PVS-Studio.log \
                            ....

Использование файла конфигурации позволяет упростить интеграцию анализатора с системами CI/CD.

Подавление сообщений анализатора и фильтрация отчёта согласно правилам подавления

В PVS-Studio существует механизм подавления предупреждений, который подходит для следующих сценариев:

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

Утилита pvs-studio-analyzer позволяет подавить сообщения анализатора и провести фильтрацию отчёта, исключив из него подавленные сообщения.

Создание baseline-уровня сообщений

Для подавления сообщений создаётся специальный файл (по умолчанию имеет имя suppress_file.suppress.json), куда записываются предупреждения анализатора, которые следует игнорировать.

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

pvs-studio-analyzer suppress [-a <TYPES>] [-f <FILE...>] \
                             [-v <NUMBER...>] [-o <FILE>] [log]
  • [log] — задаёт путь до отчёта, который был создан анализатором. По умолчанию анализатор будет искать файл PVS-Studio.log в текущей директории.
  • ‑‑analyzer [TYPES] (-a [TYPES]) — позволяет указать, предупреждения каких групп диагностических правил и их уровней достоверности будут перемещены в файл подавления. Параметр принимает строку вида Diagnostic group: Diagnostic level [, Diagnostic level]*, где Diagnostic group определяет группу диагностических правил. Возможные группы: GA, 64, OP, CS, MISRA, AUTOSAR, OWASP. Diagnostic level — уровень достоверности (возможные уровни: 1, 2, 3). Объединение разных групп и их уровней возможно через символ ; или +. Например, запись вида GA:1;OP:1 указывает анализатору подавлять только те предупреждения, которые относятся к первому уровню достоверности в группах общего анализа и микрооптимизаций. По умолчанию фильтрация применяется ко всем группам и уровням.
  • ‑‑file [FILE...] (-f [FILE...]) — позволяет подавить все предупреждения для конкретного файла:
pvs-studio-analyzer suppress -f test.cpp \
                             -f test2.cpp \
                             /path/to/PVS-Studio.log

или для конкретного файла и строки в нем:

pvs-studio-analyzer suppress -f test.cpp:15 \
                             /path/to/PVS=Studio.log
  • ‑‑warning [NUMBER...] (-v [NUMBER...]) — задаёт номер диагностики, срабатывания которой необходимо подавить из отчёта:
pvs-studio-analyzer suppress -v 512 /path/to/PVS-Studio.log
  • ‑‑output [FILE] (-o[FILE]) — задаёт путь и имя для файла подавления. По умолчанию PVS-Studio записывает всю информацию о подавлении срабатываний в файл suppress_file.suppress.json в текущей директории.

Примечание. Флаги ‑‑file, ‑‑warning и ‑‑analyzer можно комбинировать. Например, данная команда подавит все предупреждения V1040 на строке 12:

pvs-studio-analyzer suppress -f test.cpp:12 \
                             -v 1040 \
                             /path/to/PVS-Studio.log

Следующая команда подавляет все диагностические правила общего назначения 3-го уровня для файла:

pvs-studio-analyzer suppress -f test.cpp \
                             -a 'GA:3' \
                             /path/to/PVS-Studio.log

Фильтрация отчёта по suppress-файлу

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

pvs-studio-analyzer filter-suppressed [-o <FILE>] [-s <FILE>] [log]
  • ‑‑output [FILE] (-o [FILE]) — имя файла для записи отфильтрованного отчёта. По умолчанию, если флаг не задан, pvs-studio-analyzer перезапишет существующий файл отчёта.
  • ‑‑suppress-file [FILE] (-s [FILE]) — файл подавления сообщений. По умолчанию, pvs-studio-analyzer ищет файл suppress_file.suppress.json в директории запуска.
  • [log] — задаёт путь до отчёта, который был ранее создан анализатором.

Утилита pvs-studio-analyzer всегда ищет файл подавления в режиме анализа для создания фильтрованного отчёта. Если файл имеет нестандартный путь, укажите его через флаг -s:

pvs-studio-analyzer analyze -s /path/to/suppress_file.suppress.json ....

Описание кодов возврата

Утилита может возвращать следующие значения:

  • 0 — анализ прошёл успешно;
  • 1 — разнообразные внутренние ошибки. Например, не удалось препроцессировать файл или при разборе файла трассировки произошла ошибка. Как правило, падение c таким кодом сопровождается описанием ошибки в stdout;
  • 2 — срок действия лицензии истекает менее чем через месяц.
  • 3 — во время анализа некоторых файлов произошла внутренняя ошибка;
  • 5 — срок действия вашей лицензии истёк.
  • 6 — утилита была запущена с флагом ‑‑disableLicenseExpirationCheck, и ей была передана новая лицензия сроком действия более 30 дней.
  • 7 — ни одна единица компиляции не была принята к анализу. Например, все файлы были исключены из анализа с помощью настроек пользователя или путём маркировки всех директорий исходного кода как путей к системным заголовкам.
  • 8 — не было обнаружено ни одного вызова компилятора. Например, используется неизвестный компилятор или некорректно сгенерирован файл структуры проекта (strace_out или база данных команд компиляции).

В режиме trace, анализатор по умолчанию возвращает тот же код, что получил от запускаемой программы. Если же вы хотите, чтобы анализатор игнорировал настоящий код возврата и всегда возвращал 0, то можете воспользоваться флагом -i или -- ignoreTraceReturnCode.

Например:

pvs-studio-analyzer trace -i -- ....