Для получения триального ключа
заполните форму ниже
Team License (базовая версия)
Enterprise License (расширенная версия)
* Нажимая на кнопку, вы даете согласие на обработку
своих персональных данных. См. Политику конфиденциальности

Запросите информацию о ценах
Новая лицензия
Продление лицензии
--Выберите валюту--
USD
EUR
RUB
* Нажимая на кнопку, вы даете согласие на обработку
своих персональных данных. См. Политику конфиденциальности

Бесплатная лицензия PVS-Studio для специалистов Microsoft MVP
* Нажимая на кнопку, вы даете согласие на обработку
своих персональных данных. См. Политику конфиденциальности

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

Мне интересно попробовать плагин на:
* Нажимая на кнопку, вы даете согласие на обработку
своих персональных данных. См. Политику конфиденциальности

Ваше сообщение отправлено.

Мы ответим вам на


Если вы так и не получили ответ, пожалуйста, проверьте папку
Spam/Junk и нажмите на письме кнопку "Не спам".
Так Вы не пропустите ответы от нашей команды.

>
>
>
Анализатор PVS-Studio на сайте godbolt.…

Анализатор PVS-Studio на сайте godbolt.org (Compiler Explorer) и предостережение

08 Июн 2020

Мы добавили возможность экспериментировать со статическим анализатором кода PVS-Studio на сайте godbolt.org (Compiler Explorer). Поддерживается анализ C и C++ кода. Уверены, что это интересный и очень простой способ попробовать, как поведёт себя анализатор на тех или иных примерах кода. Однако у нас есть опасение, что теперь программисты начнут пытаться оценивать возможности анализатора на синтетических примерах, а не запуская на реальных проектах. Давайте попробуем разобраться, чем плох подход оценки, базирующийся на синтетических примерах.

0739_godbolt_and_caution_ru/image1.png

Compiler Explorer это интерактивный инструмент, который позволяет печатать код в одном окне и видеть результаты его компиляции в другом.

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

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

  • Зайти на сайт godbolt.org,
  • Во вкладке с выводом компилятора нажать "Add tool...",
  • В выпадающем списке выбрать "PVS-Studio".

Теперь вы можете проверять ваш код, просто вписав его в окне на сайте. На данный момент поддерживаются все версии компиляторов GCC и Clang для платформ x86 и x64.

Эта новая возможность открывает интересные перспективы с точки зрения утоления любопытства, написания статей и так далее. Однако в этом есть опасность: синтетические примеры могут быть использованы не только для экспериментов/изучения, но и для попытки оценивать и сравнивать анализаторы кода. А это очень плохой подход. Он будет слишком неточен и зависеть от того, как написан пример кода.

Наша команда уже давно столкнулась с этой проблематикой. Ещё в 2017 году я написал статью "Почему я не люблю синтетические тесты". Рекомендую почитать её, она небольшая. Сейчас я приведу ещё примеры.

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

int main()
{
  int *p = new int;
  *p = 1;
  return 1;
}

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

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

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

Стоит поменять название функции и предупреждение вернётся.

int foo()
{
  int *p = new int;
  *p = 1;
  return 1;
}

Теперь анализатор выдаст ожидаемое предупреждение: <source>:5:1: error: V773 The function was exited without releasing the 'p' pointer. A memory leak is possible.

Другой пример с функцией main. Давайте сделаем в ней вечный цикл:

int main()
{
  unsigned i = 0;
  while (1)
  {
      i++;
  }
  return 1;
}

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

И вновь, стоит поменять название функции, и анализатор выдаст предупреждение.

int foo()
{
  unsigned i = 0;
  while (1)
  {
      i++;
  }
  return 1;
}

Анализатор сообщает: <source>:4:1: note: V776 Potentially infinite loop.

Работа любого статического анализатора – это хрупкий баланс между бесконечным количеством малополезных сообщений и опасностью не сообщить про настоящую ошибку. Теперь становится понятно, почему анализаторы кода столь чувствительны к тому, как составлены примеры. И надо быть очень аккуратным при написании синтетических примеров. И вдвойне надо быть аккуратным, если с помощью таких маленьких тестов вы захотите сравнивать инструменты анализа. Лучше так не делать.

Если кто-то хочет лучше понять нашу философию реализации диагностик и отсечения ложных срабатываний, предлагаю взглянуть на две следующие статьи:

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

Теперь вы предупреждены. Пробуйте, экспериментируйте. Но будьте аккуратны в выводах.

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

Спасибо за внимание.

Популярные статьи по теме
Как различить C и C++ разработчиков по их коду

Дата: 12 Май 2022

Автор: Гость

Так уж случилось, что я пишу код для разных IoT-железок, связанных с электричеством, типа зарядных станций автомобилей. Поскольку аппаратных ресурсов, как правило, вполне достаточно, то основным фоку…
Отладочный вывод на микроконтроллерах: как Concepts и Ranges отправили мой printf на покой

Дата: 06 Май 2022

Автор: Гость

Здравствуйте! Меня зовут Александр, и я работаю программистом микроконтроллеров.
Нереальный baselining или доработки PVS-Studio для Unreal Engine проектов

Дата: 26 Апр 2022

Автор: Валерий Комаров

Статический анализатор PVS-Studio постоянно развивается: улучшаются различные механизмы, происходит интеграция с игровыми движками, IDE, CI/CD и другими системами и сервисами. Благодаря этому несколь…
Разбор некоторых вредных советов для С++ программиста

Дата: 21 Апр 2022

Автор: Андрей Карпов

Юмор юмором, но осторожность не повредит. Вдруг кому-то не до конца понятно, почему какой-то из советов является вредным. Здесь можно найти соответствующие пояснения.
Четыре причины проверять, что вернула функция malloc

Дата: 20 Апр 2022

Автор: Андрей Карпов

Некоторые разработчики пренебрежительно относятся к проверкам: удалось ли выделить память с помощью функции malloc или нет. Их логика проста – памяти всегда должно хватить. А если не хватит, всё равн…

Комментарии (0)

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