PVS-Studio. Отсчёт цен в обратную сторону

О, необычно было увидеть комментарий под статьёй более чем 10-летней давности! :)

PVS-Studio на данный момент большое B2B инструментальное средство для компаний. Анализатор совместим с ГОСТ Р 71207–2024 и может использоваться для построений процессов разработки безопасного ПО (ГОСТ Р 56939-2024). Индивидуальных лицензий нет (см. история CppCat).

Возможно, вам подойдёт вариант бесплатного лицензирования для открытых проектов или образовательная лицензия.

ГОСТ Р 56939-2024 – Разработка безопасного программного...

От теории к практике :)

Вот что получается, когда не думаешь о безопасной разработке и статическом анализе кода - Необходимость статического анализа для РБПО на примере 190 багов в TDengine

Учимся рефакторить код на примере багов в TDengine, часть 1: про колбасу

Завершение цикла публикаций про TDengine - Необходимость статического анализа для РБПО на примере 190 багов в TDengine.

Учимся рефакторить код на примере багов в TDengine, часть 2: макрос, пожирающий стек

Завершение цикла публикаций про TDengine - Необходимость статического анализа для РБПО на примере 190 багов в TDengine.

Учимся рефакторить код на примере багов в TDengine, часть 3: плата за лень

Завершение цикла публикаций про TDengine - Необходимость статического анализа для РБПО на примере 190 багов в TDengine.

ГОСТ Р 56939-2024 – Разработка безопасного программного...

Это устоявшееся мнение, но... у лабораторий и клиентов есть успешный опыт сертификации с использованием PVS-Studio :). Тем, кому интересна эта тема или есть вопросы, просим обращаться в поддержу или по телефону [phone]

ГОСТ Р 56939-2024 – Разработка безопасного программного...

Спасибо, что затронули эту интересную тему. Дело в том, что всё сложнее, чем кажется. ГОСТ Р 71207–2024 описывает методику проверки требований к статическому анализатору, но есть нюансы. Эта задача как бы остаётся на пользователях и сертификационных лабораториях. Они должны провести сложные исследования на различных наборах тестов, чтобы определить, что анализатор выявляет все типы критических ошибок, используя все необходимые технологии.

Это очень ресурсоёмкая задача, требующая глубокой экспертизы в сфере анализа кода. Получается, что пользователям самостоятельно всесторонне проверить анализаторы очень дорого и сложно. Или оценка будет носить недостоверный характер.

По идее такое исследование под силу разработчику статического анализатора, но тогда встаёт вопрос о предвзятости и достоверности испытаний. Нет и сторонних исследований и до недавнего времени не было понятно, как их организовать.

На помощь пришла ФСТЭК. ФСТЭК России объявила о начале масштабных испытаний статических анализаторов. Однако пока рано рассуждать о соответствии инструментов стандарту. Сейчас только разрабатывается сама методология испытаний статических анализаторов.

Описанное выше, кстати, чуть более подробно я и другие участники рабочей группы изложили в публикации "Испытания статических анализаторов" – мой комментарий в разделе "ПВС (участник испытаний)".

Наша команда считает, что "PVS-Studio соответствует требованиям ГОСТ Р 71207—2024 (статический анализ программного обеспечения)". Но формально всем приходится писать "разрабатывается с учётом требований", "полная совместимость с ГОСТ" (так про Svace пишут) и т.д. :)

Взгляните на ГОСТ Р 71207—2024 о статическом анализе кода глазами разработчиков PVS-Studio

Там, в смысле в ГОСТ? В стандарте про то, как правильно использовать методологию статического анализа кода и о том, что должны уметь делать инструментальные средства.

Краткий обзор можно посмотреть в докладе: https://vkvideo.ru/video-11805870_456239505

Использование статического анализатора в разработке безопасного программного обеспечения на примере PVS-Studio

vkvideo.ru

Учимся рефакторить код на примере багов в TDengine, часть 2: макрос, пожирающий стек

Следующая публикация: Учимся рефакторить код на примере багов в TDengine, часть 3: плата за лень.

Учимся рефакторить код на примере багов в TDengine, часть 1: про колбасу

Продолжение:

1. Учимся рефакторить код на примере багов в TDengine, часть 2: макрос, пожирающий стек

2. Учимся рефакторить код на примере багов в TDengine, часть 3: плата за лень

Учимся рефакторить код на примере багов в TDengine, часть 2: макрос, пожирающий стек

Логично. Теперь объект разрушается, когда завершается его область видимости, ограниченная фигурными скобками.Только это имеет перпендикулярное отношение к рассматриваемой теме. Внимательно читаем описание функции alloca. Самое важное:

Выделенная с использованием alloca память автоматически освобождается при выходе из фун­кции, которая вызвала alloca.

Учимся рефакторить код на примере багов в TDengine, часть 2: макрос, пожирающий стек

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

Функции и макросы по-разному работают. Поясняющий пример:

#include <iostream>

struct A
{
    A() { std::cout << "A()" << std::endl; }
    ~A() { std::cout << "~A()" << std::endl; }
};

#define MACROS A a;

void Function()
{
    A a;
}

void UseMacros()
{
    std::cout << "Используем макрос" << std::endl;
    MACROS
    std::cout << "Конец использования макроса" << std::endl;
}

void UseFunction()
{
    std::cout << "Используем функцию" << std::endl;
    Function();
    std::cout << "Конец использования функции" << std::endl;
}


int main() {
    UseMacros();
    std::cout << "----------------" << std::endl;
    UseFunction();
    return 0;
}

Распечатает:

Используем макрос
A()
Конец использования макроса
~A()
----------------
Используем функцию
A()
~A()
Конец использования функции

Учимся рефакторить код на примере багов в TDengine, часть 1: про колбасу

Хотя, наверное, неважной, если до сих пор не было замечено

Кстати, вы обратили внимание на интересные момент. Действительно мы часто описываем ошибки, которые скорее всего слабо влияют на поведение программы (редкий сценарий). А всё почему? Потому что вот такие разовые проверки демонстрируют работу анализатора, но не являются правильным способом его использования. Те ошибки, которые сильно влияют на работу программы уже найдены, но с большой затратой энергии. Их находили при тестировании, в процессе отладки, благодаря письмам недовольных пользователей... А ведь многие из них можно было-бы найти статическим анализатором ещё на этапе написания кода.

Обходим BitLocker и вытягиваем из памяти ключи в Windows 11

Очень может быть :) Ссылка для тех, кто не знает, про что речь :) Этого очень много везде.

Undefined behavior ближе, чем вы думаете

Путеводитель C++ программиста по неопределённому поведению: часть 2 из 11.

Путеводитель C++ программиста по неопределённому поведению

Приглашаем на вебинар "C++ и неопределённое поведение" 27 февраля 2025 в 14:00.

Хотя, скорее всего, это будет формат подкаста". Мы пригласили в гости Дмитрия Свиридкина — автора книги "Путеводитель C++ программиста по неопределённому поведению". Обсудим грани, отделяющие корректный C++ код от некорректного, попросим рассказать историю написания книги, поговорим о развитии языка и его будущем.

Путеводитель C++ программиста по неопределённому поведению

Спасибо за отзыв. Улучшения и добавления, на сколько я знаю, уже делаются Дмитрием и должны войти в печатное издание.

Дарим электронную версию книги «Вредные советы для С++ программистов»

Мм.. нет )

60 антипаттернов для С++ программиста, часть 12 (совет 56 — 60)

Для любителей длинных текстов - "Путеводитель C++ программиста по неопределённому поведению" в 12 частях :)

Главный вопрос программирования, рефакторинга и всего такого

Для любителей длинных текстов - "Путеводитель C++ программиста по неопределённому поведению" в 12 частях :)