Анализатор кода c линукс

Знакомство со статическим анализатором 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.

Источник

Хроники пикирующего дракона

От киборга для киборгов!

Страницы

1 янв. 2012 г.

Статический анализ кода на C в Linux’е

Теоретически ребенок может предпочесть общение с консолью и компилятором общению с реальными людьми, особенно если со сверстниками проблемы. Плюсы общения с машиной для него будут очевидны: даешь задание получаешь результат(кому еще ребенок может дать задание), если результат не верен, значит сам напортачил(а люди могут врать или ошибаться по морю причин и пойди разбери по какой именно). А еще у машины всегда есть время общаться с ребенком(она не скажет что устала на работе и ей нужно попить пивка).

К сожалению, поиски того, где же ты напортачил, мо гут затянуться если не использовать анализаторы кода. Там, где человек от усталости вполне может и пропустить какую-то, не вполне очевидную, ошибку, программа ничего не упустит и предупредит о том, что «здесь что-то не так».
Поскольку я пишу на C и использую GNUтые или же просто опенсорсные средства разработки (GNU Emacs, GNU GCC, Doxygen и так далее), то меня интересовали, в первую очередь, средства для статического анализа кода с открытыми исходниками. О них то, по меньшей мере о тех, которые мне приглянулись, и пойдет речь в данном посте.

Во-первых, как внезапно оказалось, некоторый анализ кода можно проводить и средствами самого компилятора gcc. Достаточно лишь задать ему набор «волшебных» ключиков, приняв которые он начнет относиться к вашему коду придирчиво и педантично.
Список ключей я сформировал на основе вот этой статьи и на основе официальной документации по компилятору gcc:

• -Wall включает предупреждения о выходах за границы массива, о неиспользуемых переменных, функциях и так далее;
• -Wextra включает предупреждения о пустых блоках в операторе if, о сравнениях signed и unsigned;
• -pedantic включает строгое следование стандарту ISO C. Всякие расширения компилятора, наподобие long long игнорируются;
• -Wconversion -Wsign-conversion дает предупреждение о преобразовании типа, при котором значение может поменяться;
• -Werror трактует все предупреждения как ошибки. Пока все предупреждения компилятора не будут исправлены — программа не скомпилируется;
• -Winit-self проверяет на наличие ошибок «самоинициализации», вида int i = i;
• -Wunreachable-code ищет участки кода, которые никогда не будут выполнены;
• -Wformat-y2k работает только вместе с -Wall и предупреждает об использовании в функции strftime() и подобных об использовании формата, который дает только последние две цифры года, вместо четырех;
• -Wformat-nonliteral предупреждает об использовании в качестве строки формата чего-то, что не является строковым литералом;
• -Wformat-security предупреждает о небезопасных применениях функций, использующих заданные форматы для работы со строками, например printf() или scanf();
• -Wformat=2 является аналогом -Wformat (включен в -Wall) -Wformat-y2k -Wformat-nonliteral -Wformat-security;
• -Wmissing-include-dirs вырабатывает предупреждение, если предоставленный пользователем каталог для заголовочных файлов не существует;
• -Wswitch-default предупреждает об отсутствии ветви default в операторе множественного выбора switch. Я встречал рекомендации всегда использовать ветвь default, поскольку нельзя гарантировать сейчас, а тем более и в будущем, что переменная, проверяемая в switch() всегда будет принимать те и только те значения, которые вы задали через case’ы;
• -Wtrigraphs предупреждает об использовании триграфов в вашей программе;
• -Wstrict-overflow=4 активно ищет, чтобы такого упростить в вашей программе. Например, компилятор теперь не пройдет мимо x + 1 > x (всегда TRUE), x + 1 > 1 (можно записать как x > 0), (x * 10) / 5 (лучше записать короче, как x * 2);
• -Wstrict-overflow=5 с этой опцией компилятор становиться еще более параноидальным и теперь он не пройдет мимо x + 2 > y, не предложив упростить до x + 1 >= y. Как мне кажется, оба варианта имеют свое право на существование, поэтому я не использую данную опцию;
• -Wsuggest-attribute=[pure|const|noreturn] данная опция проверяет наш код на наличие функций, которым не помешали бы атрибуты pure, const или noreturn. Работает вместе с опцией -fipa-pure-const (у меня почему-то не заработало ни с -fipa-pure-const ни с -O1 — достаточно новый gcc-4.5.2 просто ругается на unrecognized command line option);
• -Wfloat-equal ругается, если кто-то пытается производить некоторые проверки на равенство, используя при этом переменные типа float;
• -Wundef предупреждает если используется неизвестный идентификатор в #if;
• -Wshadow предупреждает если локальная переменная скрывает собой некую, лежащую выше по области видимости, переменную, с таким же названием;
• -Wbad-function-cast предупреждает, если результат функции приводится к неподходящему типу;
• -Wcast-qual предупреждает о приведении типа указателя, вызывающем потерю некоторого атрибута типа. Например, будет выработано предупреждение о приведении const char * к char *;
• -Wcast-align предупреждает, если указатель приводится к типу, чей размер больше, чем размер исходного типа. Например: char * к int *, если int 2 или 4-байтный;
• -Wwrite-strings вырабатывает предупреждение, если мы попытаемся присвоить адрес строковой константы const char[] указателю char *;
• -Wlogical-op предупреждает о странном использовании логических операторов в выражениях. Например, использование логических операторов в контексте, где более подошло бы использование побитовых операторов.

Источник

Статический анализатор ShellCheck и улучшение качества скриптов в Linux и Unix

Написание shell-скриптов — занятие увлекательное. Скрипты командной строки помогают автоматизировать повседневные дела. Можно создать нечто прекрасное (или какую-нибудь гадость), однако, если уж что-то писать, хорошо бы точно знать, что код получается именно таким, каким он нужен программисту. Скрипт, написанный некачественно, может представлять опасность. Большинство новичков пишут скрипты, копируя фрагменты кода со StackOverflow, находя то, что им нужно, в Google, или пользуясь сайтами с вопросами и ответами по Linux. Такой подход к программированию выливается в некачественный код и в появление ошибок. Вот, например, команда rm , выполнение которой приведёт к катастрофе, так как переменная VAR не определена:

Многие из проблем скриптов можно решить с помощью линтера, такого, как статический анализатор кода ShellCheck, который написан на Haskell. Он помогает искать ошибки в текстах скриптов и выводить отчёты о проведённых проверках. Это позволяет повысить производительность работы и качество кода. Сегодня мы расскажем о том, как установить и использовать ShellCheck в Linux и Unix-подобных операционных системах.

Установка

Самый простой способ локальной установки ShellCheck заключается в использовании применяемого в вашем дистрибутиве менеджера пакетов вроде apt/apt-get/yum и других.

▍Установка ShellCheck в Debian/Ubuntu Linux

Тут понадобится следующая команда apt / apt-get:

Вот пример реакции системы на эту команду:

▍Установка ShellCheck в CentOS/RHEL/Fedora/Oracle Linux

Сначала нужно включить репозиторий EPEL в CentOS/RHEL:

Дальше надо ввести следующую команду yum:

Вот что будет выведено в ответ на эту команду:

Если вы пользуетесь Fedora, выполните следующую команду dnf:

▍Установка ShellCheck в Arch Linux

Введите следующую команду pacman:

▍Установка ShellCheck в Gentoo Linux

Введите такую команду emerge:

▍Установка ShellCheck в OpenSUSE Linux

Введите следующую команду zypper:

▍Установка ShellCheck в macOS Unix

Воспользуйтесь следующей командой port если вы работаете с MacPorts:

Если вы пользуетесь Homebrew в macOS/OS X, введите такую команду brew:

Как пользоваться ShellCheck

Испытаем ShellCheck на скрипте, содержимое которого просмотрим с помощью команды cat:

Теперь проверим скрипт с помощью ShellCheck:

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

ShellCheck в действии

Утилита ShellCheck предложила внести исправления, касающиеся использования переменных, не заключённых в кавычки, а также сообщила о других проблемах. Исправим ошибки и снова просмотрим текст скрипта следующей командой:

Вот что, в итоге, получилось:

Интеграция ShellCheck в текстовый редактор

Для установки ansible-vim и neomake/neomake , введите в vim следующую команду:

Для использования плагина введите следующую команду, редактируя bash/sh-скрипт:

Вот как выглядят результаты работы плагина в редакторе:

Neomake выводит предупреждения и сообщения об ошибках с помощью ShellCheck

Итоги

Полагаем, ShellCheck — это замечательный инструмент, который позволяет улучшать и исправлять скрипты командной строки Linux. Он способен обнаруживать множество распространённых недоработок и ошибок в их коде. Если вы хотите узнать о SpellCheck больше — вот сайт проекта, а вот — его репозиторий на GitHub.

Уважаемые читатели! Проверяете ли вы свои скрипты чем-то вроде ShellCheck?

Источник