В канун празднования нового 2019 года команда PVS-Studio решила сделать приятный подарок всем контрибьюторам open-source проектов, хостящихся на GitHub, GitLab или Bitbucket. Им предоставляется возможность бесплатного использования статического анализатора PVS-Studio для развития открытых проектов.

Это классическая статья о том, как наша команда проверила открытый проект LibrePCB с помощью статического анализатора кода PVS-Studio. Однако статья интересна тем, что проверка осуществлялась внутри Docker контейнера. Если вы использует контейнеры, то надеемся, что статья продемонстрирует ещё один простой способ встроить анализатор в процесс разработки.

Начиная с версии 6.27 статический анализатор кода PVS-Studio может классифицировать свои предупреждения согласно стандартам MISRA C и MISRA C++. Благодаря поддержке этих стандартов анализатор стало возможным эффективно использовать для улучшения безопасности, переносимости и надежности программ для встраиваемых систем.

Предлагаю вниманию прототип статьи под названием «Бесплатный PVS-Studio для всех, кто развивает открытые проекты на GitHub». Прошу подойти к данной теме конструктивно и высказывать предложения и критику по делу. Интересно мнение, насколько предложенный вариант разумен и удобен? Что можно улучшить? Какие дополнительные ограничения можно добавить? Кто бы из вас воспользовался/не воспользовался и почему?

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

Время от времени нам задают вопрос, какую пользу в денежном эквиваленте получит компания от использования анализатора PVS-Studio. Я решил реализовать на сайте ROI-калькулятор и разместить подробное описание принципов его работы. Но прежде я решил вынести свои мысли и расчёты на обсуждение. Я надеюсь получить интересные и полезные комментарии, которые помогут сделать калькулятор как можно более достоверным и убедительным.

Вашему вниманию предлагается описание калькулятора, позволяющего рассчитать возврат инвестиций от использования в процессе разработки статического анализатора кода PVS-Studio.

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

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

Термин «современный C++» часто используется как синоним выражения «код, использующий новый стандарт C++». Здесь «новый» может означать что угодно от C++11 до C++17, или даже то, что уже сейчас доступно из C++20. Я думаю, что современный C++ — это нечто большее, не ограничивающееся добавлением флага -std=c++17.

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

Примечание от переводчика: в русском языке нет четкого соответствия в употребляемом контексте слова «wrap»/«wrapping». Существует математический термин "перенос", который близок к описываемому явлению, а термин "флаг переноса" (carry flag) — механизм выставления флага в процессорах при целочисленном переполнении. Другим вариантом перевода может быть фраза «вращение/переворот/оборот вокруг нуля». Она лучше отображает смысл «wrap» по сравнению с «перенос», т.к. показывает переход чисел при переполнении из положительного в отрицательный диапазон. Однако, как оказалось, эти слова смотрятся в тексте непривычно для тестовых читателей. Для упрощения в дальнейшем примем в качестве перевода термина «wrap» слово «перенос».

Компиляторы языка C (и C++) в своей работе всё чаще руководствуются понятием неопределённого поведения — представлением о том, что поведение программы при некоторых операциях не регламентировано стандартом и что, генерируя объектный код, компилятор вправе исходить из предположения, что программа таких операций не производит. Немало программистов возражало против такого подхода, поскольку сгенерированный код в этом случае может вести себя не так, как задумывал автор программы. Эта проблема становится всё острее, так как компиляторы применяют всё более хитроумные методы оптимизации, которые наверняка будут опираться на понятие неопределённого поведения.

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

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

Обычно мы не пишем заметки про выход новой версии анализатора PVS-Studio. Однако в новый релиз вошло много интересных изменений, касающихся анализа C и C++ кода, о которых хочется рассказать нашим пользователям.

Время от времени наша команда повторно проверяет проекты, про которые мы уже писали статьи. Очередным таким перепроверенным проектом стал Qt. Последний раз мы проверяли его с помощью PVS-Studio в 2014 году. Начиная с 2014 года проект начал регулярно проверяться с помощью Coverity. Это интересно. Давайте посмотрим, удастся ли нам теперь найти какие-то интересные ошибки с помощью PVS-Studio.

Изучая предупреждения анализатора PVS-Studio в процессе проверки различных открытых проектов, мы вновь и вновь убеждаемся, сколь полезен может быть этот инструмент. Анализатор кода невероятно внимателен и никогда не устаёт. Он указывает на ошибки, которые ускользают даже при внимательном обзоре кода. Рассмотрим очередной такой случай.

0 A.D. — это трёхмерная игра в жанре исторической стратегии в реальном времени, разрабатываемая сообществом добровольцев. Размер кодовой базы маленький и я решил проверить игру в качестве отдыха от больших проектов, таких как Android и XNU Kernel. Итак, перед нами проект, содержащий 165000 строк кода на языке C++. Посмотрим, что интересного в нём можно найти с помощью статического анализатора PVS-Studio.

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


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

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

Указатель ссылается на ячейку памяти, а разыменовать указатель — значит считать значение указываемой ячейки. Значением самого указателя является адрес ячейки памяти. Стандарт языка C не оговаривает форму представления адресов памяти. Это очень важное замечание, поскольку разные архитектуры могут использовать разные модели адресации. Большинство современных архитектур использует линейное адресное пространство или аналогичное ему. Однако даже этот вопрос не оговаривается строго, поскольку адреса могут быть физическими или виртуальными. В некоторых архитектурах используется и вовсе нечисловое представление. Так, Symbolics Lisp Machine оперирует кортежами вида (object, offset) в качестве адресов.

Новая версия PVS-Studio 6.23 работает под управлением macOS и позволяет проверять проекты, написанные на языке C и C++. К этому событию наша команда решила приурочить проверку XNU Kernel.

PVS-Studio для macOS

С выходом версии анализатора для macOS, PVS-Studio можно смело называть кроссплатформенным статическим анализатором кода для C и C++.

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