Даже если обнаружила, это ничего не меняет. Ведь в коде то ошибки есть, а значит среда разработки не заменяет классические анализаторы кода, такие как PVS-Studio.
Они по разному используется. Задача среды - по возможности подсветить ошибки (пойдя на компромисс между глубиной анализа и скоростью).
Задача статического анализатора – провести глубокий анализ и предоставить гибкую многоуровневую систему контроля качества кода. Если разработчик не заметит/проигнорирует ошибку на этапе написания или закладке кода, то предупреждения будут разосланы, например после ночной проверки. В том числе, письмо с багами придёт тимлиду и он придёт к автору кода с наставлениями :) Это один из сценариев, возможны и другие.
Это не так работает. Никто никому ничего не всовывает :). Цель пообщаться с людьми, рассказать про продукт, ответить на вопросы. Но для этого, люди в начале должный подойти к стенду. Для этого нужна раздатка и другие способы привлечения. Люди неохотно подходят к пустым стендам. Описываемое - это просто первый шаг, чтобы начать общаться.
Согласен: у таких статей есть проблема однообразия. Мы стараемся как-то обыгрывать ошибки, экспериментируем с подачей материала и так далее. Но не всегда получается. С другой стороны, такие регулярные статьи про проверку проектов всё равно нужны.
Они вновь и вновь демонстрируют пользу анализаторов кода. Иначе возникнет ощущение, что проблема багов решена и тема анализаторов не актуальна. Мол компиляторы/среды разработки/AI-тулы и так всё уже находят. Или программисты наконец научились писать без ошибок :). Можно расслабиться :).
На самом деле ничего не меняется. По-прежнему нужны продвинутые инструменты анализа кода, дополняющие другие методологии борьбы с ошибками (обзоры кода, динамический анализ, юнит-тесты и так далее). Способ убедительно это продемонстрировать – найти ошибки в проекте. Поэтому писали, пишем и будем писать про найденные баги :)
Please, open merge requests or specific issues, instead of pointing to a blog post.
Надеюсь, найдётся желающий всё это сделать. Я считаю свою часть работы сделанной. У меня нет ресурсов заниматься по отдельности с каждым багом в каждом проверяемом проекте :(
Разница в том, что анализатор знает, что такое 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? Нет границы или критерия где надо остановиться, реализуя подобные диагностики.
Относитесь проще. Всё это носит развлекательный характер, а не, например, для проведения собеседований :)
Это ограничения сайта при публикации статьи. Не будьте так строги. :)
Не стоит предсказывать, как оно будет :)
Ложные представления программистов о неопределённом поведении.
Новая серия: Предновогоднее шоу: Топ 10 ошибок в C и С++ проектах в 2023 году.
Даже если обнаружила, это ничего не меняет. Ведь в коде то ошибки есть, а значит среда разработки не заменяет классические анализаторы кода, такие как PVS-Studio.
Они по разному используется. Задача среды - по возможности подсветить ошибки (пойдя на компромисс между глубиной анализа и скоростью).
Задача статического анализатора – провести глубокий анализ и предоставить гибкую многоуровневую систему контроля качества кода. Если разработчик не заметит/проигнорирует ошибку на этапе написания или закладке кода, то предупреждения будут разосланы, например после ночной проверки. В том числе, письмо с багами придёт тимлиду и он придёт к автору кода с наставлениями :) Это один из сценариев, возможны и другие.
Это не так работает. Никто никому ничего не всовывает :). Цель пообщаться с людьми, рассказать про продукт, ответить на вопросы. Но для этого, люди в начале должный подойти к стенду. Для этого нужна раздатка и другие способы привлечения. Люди неохотно подходят к пустым стендам. Описываемое - это просто первый шаг, чтобы начать общаться.
Согласен: у таких статей есть проблема однообразия. Мы стараемся как-то обыгрывать ошибки, экспериментируем с подачей материала и так далее. Но не всегда получается. С другой стороны, такие регулярные статьи про проверку проектов всё равно нужны.
Они вновь и вновь демонстрируют пользу анализаторов кода. Иначе возникнет ощущение, что проблема багов решена и тема анализаторов не актуальна. Мол компиляторы/среды разработки/AI-тулы и так всё уже находят. Или программисты наконец научились писать без ошибок :). Можно расслабиться :).
На самом деле ничего не меняется. По-прежнему нужны продвинутые инструменты анализа кода, дополняющие другие методологии борьбы с ошибками (обзоры кода, динамический анализ, юнит-тесты и так далее). Способ убедительно это продемонстрировать – найти ошибки в проекте. Поэтому писали, пишем и будем писать про найденные баги :)
Спасибо. Приятно слышать положительные отзывы о наших статьях в комментариях или на конференциях.
А теперь статья: Что нового в .NET 8?
Да, но нет.
Надеюсь, найдётся желающий всё это сделать. Я считаю свою часть работы сделанной. У меня нет ресурсов заниматься по отдельности с каждым багом в каждом проверяемом проекте :(
Часть попала из subprojects.
Продолжение темы 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, просто. К сожалению, это путь в никуда. Если придерживаться логики "ругаться на всё, в чём нет уверенности в безопасности" приведёт к такому количеству срабатываний, что анализатором пользоваться будет невозможно. Мы придерживаемся другой философии, которую я описал в этой статье. Цитата оттуда:Прошу пояснить, какую реакцию Вы ожидаете здесь от анализатора.
Неожиданное продолжение про простую ошибку разыменования нулевого указателя: FreeCAD и C++ код с неопределённым поведением для медитации (схожий случай).