Директор по маркетингу
Проверяя код проекта TDengine с помощью PVS-Studio, можно встретить код с запахом, канонические ошибки и опечатки. Многое из этого можно избежать, если изначально аккуратно оформлять код, делать логику простой и избегать макросов. Давайте рассмотрим некоторые фрагменты кода и подумаем, как можно провести его рефакторинг так, чтобы багам просто не было там места.
Проверяя код проекта TDengine с помощью PVS-Studio, можно встретить канонические ошибки и опечатки. Многих из них можно избежать, если изначально аккуратно оформлять код, делать логику простой и избегать макросов. Давайте посмотрим на эти ошибки и подумаем, как можно повести рефакторинг кода так, чтобы им просто не было там места.
В 2024 году вышел ГОСТ Р 71207 — Статический анализ программного обеспечения. Однако пользователям анализаторов сложно определять, насколько тот или иной инструмент соответствует критериям, изложенным в стандарте. Поэтому ФСТЭК России в 2025 году организует испытания статических анализаторов, результаты которых будут опубликованы в конце года. Ближайший этап — это выработка критериев оценки, и я решил предварительно изложить некоторые мысли по этой теме, которые, возможно, будут интересны жюри и участникам.
Вашему вниманию предлагается полный список разделов электронной книги (12 из 11 :)), посвящённой неопределённому поведению. Книга не является учебным пособием и рассчитана на тех, кто уже хорошо знаком с программированием на C++. Это своего рода путеводитель C++ программиста по неопределённому поведению, причём по самым его тайным и экзотическим местам. Автор книги — Дмитрий Свиридкин, редактор — Андрей Карпов.
Инструментальное средство PVS-Studio разрабатывается с учётом требований, предъявляемых к статическим анализаторам в ГОСТ Р 71207–2024, выявляет критические ошибки и может использоваться при разработке безопасного программного обеспечения. Рассмотрим функциональные возможности, реализованные в PVS-Studio на конец 2024 года в отношении анализа исходного кода программного обеспечения, написанного на компилируемых языках программирования C, C++, C#, Java.
Статический анализатор PVS-Studio способен находить ошибки даже в таком качественном и протестированном проекте, как LLVM. Чтобы это не было пустыми словами, мы время от времени перепроверяем проект и публикуем такие заметки, как эта.
В своей обители в Р'лайхе мёртвый Ктулху спит в ожидании своего часа. А в C коде проекта DPDK спит множество ошибок, и тоже в ожидании своего часа. Давайте посмотрим, какие из них может выявить анализатор PVS-Studio.
Давно хотелось написать статью, что юнит-тесты — это хорошо, но не стоит забывать, что они тоже могут содержать ошибки. Сейчас встретился проект DPDK, тесты которого хорошо демонстрируют этот нюанс. Давайте посмотрим, как выглядят типичные ошибки в юнит-тестах, и как они выявляются с помощью статического анализа кода.
Сразу предупреждаю, мои вкусы очень специфичны. Красота ошибки в том, что человеку её очень сложно найти. Я не верю, что её можно заметить при обзоре кода. Если только заранее знать, что она есть, и искать её целенаправленно.
Ошибку я нашёл в проекте DPDK. В нём есть и другие ошибки, но про них потом. Они меркнут перед этим алмазом. Только не ждите чего-то эдакого. Ошибка проста до безобразия. Вот только найти её, просматривая код, ой как непросто. Собственно, попробуйте сами.
Помню 100500 лет назад (ну ладно, всего 12), я писал на Хабре, что мне не хватает в России хардкорной C++ конференции. Затем появилась C++Russia. Навизуализировал.
Пару лет назад я начал грустить, что нет подходящей конференции на тему безопасности. Статью на эту тему я не писал, но желание исполнилось и даже побыстрее, чем с C++. Хочу познакомить вас с конференцией SafeCode.
1 апреля 2024 года введён в действие новый ГОСТ "Статический анализ программного обеспечения". Если в ГОСТ Р 56939–2016 говорится о необходимости использования статического анализа при разработке безопасного программного обеспечения (РБПО), то ГОСТ Р 71207–2024 уточняет, что именно это означает.
В стандарте:
Информация в ГОСТ очень плотная, и её тяжело сразу воспринять, если вы ранее не имели дело со статическим анализом кода и РБПО. Поэтому я подготовил и провёл цикл из 5 вебинаров, где разобрал различные аспекты ГОСТ и примерами пояснил некоторых термины.
Вебинары вытекают один из другого, но в принципе они достаточно независимые, и вы можете начать знакомиться с новым ГОСТ с просмотра любого из них. Но обо всём по порядку.
Если спросить программиста, какие баги чаще всего можно встретить в C и C++ коде, он назовёт разыменование нулевого указателя, неопределённое поведение, выход за границу массива и другие, на его взгляд, типовые паттерны ошибок. Скорее всего, он назовёт и случайное присваивание в условии. Но действительно ли эта ошибка распространена в наше время?
В этой статье мы рассмотрим, как правильно разрушать объекты в ООП программе на языке C++, не выполняя избыточных операций. Этим мы завершим цикл публикаций, посвящённый обзору ошибок в игровом движке qdEngine.
В первой статье про qdEngine было рассмотрено 10 ошибок, выбранных плагином PVS-Studio. Однако есть ещё 10 багов, заслуживающих внимания. Как говорится, лучше учиться на чужих ошибках. Заодно они хорошо демонстрируют возможности PVS-Studio в выявлении разнообразнейших ошибочных паттернов.
В этой статье мы рассмотрим, как статический анализатор PVS-Studio воодушевляет заняться рефакторингом кода. Ведь чем короче, проще и понятнее код, тем меньше в нём ошибок.
Баги, которые удалось найти в движке qdEngine, оказались весьма разнообразны, поэтому не хочется мешать всё в кучу в одной публикации. Читатели могут упустить интересные темы, связанные с написанием качественного кода. Поэтому разбор проекта выйдет в виде серии публикаций, первая из которых посвящается наиболее интересным срабатываниям с точки зрения плагина PVS-Studio.
Статические анализаторы помогают не только обнаруживать ошибки и дефекты безопасности, но и делать код чище. Выявляя лишние проверки, дублирующие действия и другие аномалии, можно сделать код проще, красивее и легче для чтения. Разберём это на практическом примере рефакторинга функции.
Команда PVS-Studio в целом и я в частности активно участвуем в различных конференциях, подкастах, митапах и других мероприятиях. Нового в этом нет, но есть пара причин сделать маленькую заметку на эту тему.
Первая причина — предложить тем, кто интересуется нашим блогом на Хабре, подписаться на рассылку/телеграм/группу, чтобы не пропустить мероприятие, где можно пообщаться с нами. Живое общение — это всегда интересно.
Вторая причина — ещё раз озвучить, что мы открыты к сотрудничеству и готовы пообщаться с организаторами митапов, DevRel-ами компаний и т.д. Напишите нам.
Я согласен, что ошибка выделения памяти с помощью malloc редкая ситуация, и после такой ошибки, скорее всего, невозможно полноценное функционирование программы. Но меня удивляет, с каким упорством программисты, приводя эти аргументы, предлагают вообще ничего не делать в такой ситуации. Я не призываю всех делать сложные механизмы восстановления работы после нехватки памяти или использовать заранее выделенные резервные буферы. Многим программам не нужны такие сложные механизмы. Тем не менее я не понимаю, почему хотя бы минимально не обработать такие ситуации корректно. Раз других объяснений пока не хватило, попробую в этот раз рассказать короткую притчу.
Указатель, который вернула функция malloc, необходимо проверить перед использованием. Неправильным решением будет использовать для этого макрос assert. В этой статье мы разберём, почему это является антипаттерном.