Мы используем куки, чтобы пользоваться сайтом
было удобно.
Мы ответим вам на
Если вы так и не получили ответ, пожалуйста, проверьте папку
Spam/Junk и нажмите на письме кнопку "Не спам".
Так Вы не пропустите ответы от нашей команды.
Это тот случай, когда ответ на комментарий перерос в небольшую заметку для блога. Мощь анализатора PVS-Studio заключается не только в том, какие ошибки может он обнаружить, но и в том, как он это делает.
Время от времени читатели наших статей оставляют комментарии, что ту или иную ошибку можно найти, не используя PVS-Studio, а просто включив соответствующее предупреждение компилятора. Да, это действительно так. Однако на практике этими предупреждениями компиляторов не так уж получается пользоваться.
Если бы всё было так просто, то не существовала бы база примеров ошибок, которые обнаружила наша команда в открытых проектах. На момент написания этой заметки мы выявили более 14000 ошибок в таких проектах, как Qt, Chromium, CMake, GTK 4. Кстати, код компиляторов (GCC 10, Clang 11) не является исключением, что даёт нам ещё один повод задуматься :).
В чем же причина, что ошибки ждали PVS-Studio, хотя часть из них вполне обнаруживается компиляторами? Все просто: проблематично взять и включить все эти предупреждения. Слишком много шума, с которым очень сложно работать.
Помимо того, что PVS-Studio опережает компиляторы по диагностическим возможностям, есть ещё два важных преимущества:
Наша команда много работает для уменьшения количества ложных срабатываний. Однако нельзя гарантировать, что при первом запуске анализатора на произвольном проекте вы не получите гору бессмысленных предупреждений. Например, в проекте на языке C достаточно пары неудачных макросов, которые испортят всю картину и приведут к тысячам ложных предупреждений.
Важно, что в случае c PVS-Studio эта ситуация не является проблемой. Вот практический пример, как небольшая настройка для C++ проекта привела к тому, что только 10–15% срабатываний оказываются ложными. Это возможно благодаря комментариям, подавляющим предупреждения в макросах, и другим разнообразным настройкам. С компиляторами обычно так просто не получается. В итоге ошибки проще найти с помощью PVS-Studio, а не компилятора.
Если вас волнует вопрос, насколько проработан процесс интеграции анализатора в большой проект, то отправляю вас к статье: Как внедрить статический анализатор кода в legacy проект и не демотивировать команду.
Написать всё это сподвиг комментарий на GitHub к описанию найденной нами красивой ошибки в проекте COVID-19 CovidSim Model. Комментарий:
Merged - thank you. It's in some new code we're not yet using, and it's a missed simple compiler warning actually - it doesn't really demonstrate the power of PVS, re the first post. When we eventually fix all the tiny "fscanf return value ignored" style warnings leftover, we may treat warnings as errors in the future to spot these sort of things earlier.
Да, эту ошибку можно обнаружить с помощью компилятора. Но факт остаётся фактом, найдена она именно с помощью анализатора PVS-Studio. Использование для этих целей компилятора – пока только мечта и требует большой работы.
Если включить в Visual C++ четвёртый уровень предупреждений (/W4), то одно из сообщений действительно укажет на описанную ошибку. Но для этого нужно "продраться" приблизительно через 150 предупреждений:
Анализатор PVS-Studio также генерирует около 150 предупреждений общего назначения, но при этом чётче отделяет важное от второстепенного. На первом уровне достоверности находятся только 3 предупреждения, одно из которых и указывает на ту самую ошибку использования неинициализированной переменной:
Я предлагаю не ждать светлого будущего, когда компилятор можно будет настроить на максимальный режим поиска ошибок. Воспользуйтесь статическим анализатором PVS-Studio и найдите сразу как можно больше ошибок. А чтобы начать использовать анализатор регулярно, примените механизм массового подавления предупреждений (задайте baseline). Для удобства PVS-Studio может интегрироваться в различные системы CI. Далее подавленные предупреждения можно рассматривать как некритичный технический долг, от которого можно постепенно избавляться. Ещё раз отсылаю за подробностями к этой статье.
Если вы разработчик открытого проекта, то вы можете воспользоваться вариантом бесплатного лицензирования.
Если у вас остались вопросы, то, возможно, на большинство из них ответит статья "Причины внедрить в процесс разработки статический анализатор кода PVS-Studio". Спасибо за внимание.
0
0
0
0