Pull to refresh
587
0
Андрей Карпов @Andrey2008

Директор по маркетингу

Send message

Даже если обнаружила, это ничего не меняет. Ведь в коде то ошибки есть, а значит среда разработки не заменяет классические анализаторы кода, такие как PVS-Studio.

Они по разному используется. Задача среды - по возможности подсветить ошибки (пойдя на компромисс между глубиной анализа и скоростью).

Задача статического анализатора – провести глубокий анализ и предоставить гибкую многоуровневую систему контроля качества кода. Если разработчик не заметит/проигнорирует ошибку на этапе написания или закладке кода, то предупреждения будут разосланы, например после ночной проверки. В том числе, письмо с багами придёт тимлиду и он придёт к автору кода с наставлениями :) Это один из сценариев, возможны и другие.

Это не так работает. Никто никому ничего не всовывает :). Цель пообщаться с людьми, рассказать про продукт, ответить на вопросы. Но для этого, люди в начале должный подойти к стенду. Для этого нужна раздатка и другие способы привлечения. Люди неохотно подходят к пустым стендам. Описываемое - это просто первый шаг, чтобы начать общаться.

Согласен: у таких статей есть проблема однообразия. Мы стараемся как-то обыгрывать ошибки, экспериментируем с подачей материала и так далее. Но не всегда получается. С другой стороны, такие регулярные статьи про проверку проектов всё равно нужны.

Они вновь и вновь демонстрируют пользу анализаторов кода. Иначе возникнет ощущение, что проблема багов решена и тема анализаторов не актуальна. Мол компиляторы/среды разработки/AI-тулы и так всё уже находят. Или программисты наконец научились писать без ошибок :). Можно расслабиться :).

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

Спасибо. Приятно слышать положительные отзывы о наших статьях в комментариях или на конференциях.

PVS-Studio у нас теперь в CI, и подобные ошибки больше просто не накапливаются

Да, но нет.

Please, open merge requests or specific issues, instead of pointing to a blog post.

Надеюсь, найдётся желающий всё это сделать. Я считаю свою часть работы сделанной. У меня нет ресурсов заниматься по отдельности с каждым багом в каждом проверяемом проекте :(

Продолжение темы Flipper Zero: зарождение идеи, вдохновение и отсылки, основной функционал, мировой успех, безопасность и ответственность, что нового.

Интервью с разработчиками мультитула для хакеров и пентестеров Flipper Zero.

Достаточно оперативно начали вносить правки. Молодцы. А то бывает, по пол года-год висят подобные issues. А то и по... :)

Разница в том, что анализатор знает, что такое malloc. И к сожалению (пока) не знает, что такое getViewObject. Его можно научить с помощью углубления технологий анализа (межпроцедурный анализ, межмодульный анализ) или за счёт явной аннотации методов.

Дело не в том может или не может указатель быть нулевым. Важно, чтобы анализ был полезен. А для этого надо ругаться ТОЛЬКО там, где есть информация/повод.

Прошу прочитать статью "Философия статического анализатора PVS-Studio". Там как раз про это. Опасность нулевого указателя ничем не отличается от опасности сложения двух переменных типа int. При сложении может возникнуть переполнение, приводящее к UB. Но ничего хорошего не будет, если ругаться на каждое сложение, если нет уверенности в его безопасности.

P.S. Это тогда уж проще на каждую строчку кода на всякий случай ругаться :) "У вас строчка кода на языке C++! Она может содержать ошибку" - совершенное точное предупреждение и совершенно бесполезное :)

В первом случае, анализатор ничего не знает про указатели (межпроцедурный+межмодульный анализ не смог вычислить, есть ли вариант, когда указатель нулевой).

Во втором случае, есть артефакт.

auto oldAnchor = detail->AnchorPoint.getValue();

if (detail) {

Есть разыменование указателя. Есть его последующая проверка. Значит, программист предполагал, что указатель может быть нулевой. Подробнее: Пояснение про диагностику V595.

Если проверки if ( detail)не будет и анализатор не сможет вычислить , может ли detail быть нулевым, то предупреждения не будет.

Вопрос про malloc не понятен. Хотя, это не важно. Функция malloc может вернуть NULL, а значит указатель может быть нулевым (и его надо проверять до использования). Тут и гадать не надо :)

Ругаться, на разыменование указателей, которые предварительно не проверены на nullptr, просто. К сожалению, это путь в никуда. Если придерживаться логики "ругаться на всё, в чём нет уверенности в безопасности" приведёт к такому количеству срабатываний, что анализатором пользоваться будет невозможно. Мы придерживаемся другой философии, которую я описал в этой статье. Цитата оттуда:

Есть два философских подхода в реализации статических анализаторов кода:

  • Ругаемся на всё, про что не можем сказать, что оно правильное.

  • Ругаемся на то, которое по какой-то причине скорее всего неправильное.

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

К нам поступают предложения по диагностикам следующего вида:

  • Следует выдавать предупреждение на A / B, если нет уверенности, что B != 0.

  • Следует выдавать предупреждение, если нет уверенности, что при вызове функции strcpy(DST, SRC) буфер DST достаточного размера.

  • Следует выдавать предупреждение при разыменовывании указателя, если нет уверенности, что pointer != NULL.

  • Следует выдавать предупреждение на sqrt(X), если нет уверенности, что X >= 0.

  • И так далее.

По отдельности каждое из таких предупреждений выглядит разумным и полезным. Но вместе они убьют анализатор кода. Каждая диагностика, реализованная подобным образом, порождает большое количество ложных срабатываний. Конечно, если реализовать только одну диагностику, беды не случится. Однако, если мы реализуем поиск делений, в которых не уверены, то почему мы должны не реализовывать поиск недостоверных sqrt? Нет границы или критерия где надо остановиться, реализуя подобные диагностики.

Прошу пояснить, какую реакцию Вы ожидаете здесь от анализатора.

Неожиданное продолжение про простую ошибку разыменования нулевого указателя: FreeCAD и C++ код с неопределённым поведением для медитации (схожий случай).

Это было интересно. Обычно, я что-то такое пишу. А тут довелось самому поиграть в угадайку. Спасибо.

Кстати, пример с int a = index + pockets[++index]; напомнил мне про наш один вопрос - Глубина кроличьей норы или собеседование по C++ в компании PVS-Studio :)

P.S. А кому интересно узнать про глубину глубин с Unicode, приглашаю сюда - Атака Trojan Source для внедрения в код изменений, незаметных для разработчика.

Спасибо за статью. По духу близко к моей подборке вредных советов :)

Пара мыслей про описанные баги.

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

И наоборот, ошибка с исчезновением memset кажется чем-то экзотическим и редким. Но это очень распространённая потенциальная уязвимость. Мы их обнаружили 100500 штук и продолжает обнаруживать. Хотя, казалось бы на эту тему тоже уже много написано: CWE-14, Zero and forget -- caveats of zeroing memory in C, Безопасная очистка приватных данных.

Information

Rating
Does not participate
Works in
Date of birth
Registered
Activity

Specialization

Specialist
C++
C
Software development