О российских анализаторах кода
Есть интересная статья в блогах на эту тему: http://alexanius-blog.blogspot.com/2012/01/pvs.html
Нет желания оголотело хвалить или ругать любой из существующих анализаторов кода, интересней было бы начать со статистических исследований, понять какие из типов дефектов более распространены в реальном коде программ, наложить на это CWSS и выстроить приоритеты по автоматизации анализа.
Статья как раз идет с этих позиций, проводя сравнение эффективности работы анализатора по разным типам дефектов, приведем ниже выдержки из неё.
PVS под лупой
В этой заметке будет рассмотрен PVS-Studio более внимательно. Для оценки работы инструментов статического анализа я создал несколько простеньких примеров и собираюсь рассказать как себя на них проявил этот инструмент. Итак, тестируется версия PVS-Studio 4.51, работа общего анализатора.
Итак, из того, что PVS смог найти:
- случай возврата указателя на локальный объект
- отсутствие возвращаемого значения
- выход за границу статического значения
- присваивание внутри условного оператора (например if( a = true ))
- множественное изменение одной переменной
К сожалению, почти полностью отсутствует работа с памятью. Не определяются случаи утечек, двойного освобождения или некорректного применения new и delete[]. Вообще, оно не декларировалось в списках возможностей, но могло бы значительно повысить качество анализа.
Также отсутствует анализ использования переменных. Например, не проверяется факт инициализации переменной или факт её неиспользования.
Отсутствует проверка соответствия типов, что тоже несколько напрягает. Особенно странно, что на моих примерах не обработался typedef.
Резюме: довольно странно, что в инструменте анализа C++ не реализованы обработки многих распространённых ошибок. Поэтому пока что он плохо подходит для общего анализа кода (тот же свободный cppcheck выполняет многое из перечисленного). Сейчас я не стал бы покупать PVS для улучшения качества своих приложений, а воспользовался бы альтернативными решениями.
Андрей, может не совсем по теме, а могли бы вы назвать просто основные преимущества вашего анализатора АК-ВС, ну, если хотите, и PVS без перечисления недостатков. 🙂
Мифы о статическом анализе. Миф пятый – можно составить маленькую программу, чтобы оценить инструмент:
http://www.viva64.com/ru/b/0119/
И ещё мысли:
1. Мы не пытаемся искать ошибки (пока по крайней мере), которые намного лучше находятся динамическим анализом. Во-первых, это очень сложно. Во-вторых, все равно высока вероятность ложного срабатывания или наоборот отсутствие позитивного срабатывания. В реальном приложении толку от статического анализа в поиске таких ошибок мало. Достаточно разнести выделение/использование/освобождение памяти по разным функциям, добавить логики, и фиг какой статический анализатор что-то найдет. Практически всегда они могут обнаружить только очень простые ситуации. Подобные, как в этих примерах. Так зачем делать заведомо то, от чего будет мало толку? Чтобы найти описываемые ошибки в реальном приложении, фактически нужно виртуально выполнить часть программы. Так не проще ли сразу использовать динамический анализатор кода?
2. Беда в том, что программисты только думают, что они знают, какие ошибки распространены. Это как с оптимизацией. Программист уверенно назовет несколько мест, где его программа тормозит. Вот только с вероятностью 90% он ошибается. Именно для этого и служат профилировщики, которые находят настоящие медленные места.
Аналогично и с типами ошибок. Все называют утечки памяти, выход за границы массива, нулевые указатели и тому подобное. И ещё ни один не назвал, опечатки, Copy-Paste или скажем сравнение вида unsigned_var >= 0. А я уверен, что именно эти ошибки самые распространенные и именно мы их учимся ловить в первую очередь. Программистам, не ловко что ли, даже себе признаться, что они просто ошибаются в словах и буквах. 🙂
К этому и относится мое утверждение, что подобные синтетические примеры имеют мало смысла. Они не отражают картину того, какие на самом деле дефекты распространены. Правильный вариант сравнения только один. Взять проект и проверить его двумя анализаторами. И сравнить, сколько реальных дефектов найдено. Ещё потом это число можно поделить на количество ложных срабатываний. А то выиграет анализатор, который ругается на каждую строчку. 🙂