На просторах сети расположен блог "No Marketing Bullshit". Неизвестный автор блога по всей видимости является одни из наших поклонников, о чем свидетельствует пара заметок на тему анализатора кода PVS-Studio. Я решил перевести одну из этих заметок. На всякий случай отмечу, что мы никакого отношения к этому блогу не имеем. Это не наш стиль. Если мы собираемся написать рекламную статью, то мы не маскируемся, а так и пишем — это рекламная статья.
Кроме печального факта о том, что невозможно попробовать Coverity не пройдя Coverity Sales Force Approval, следующим большим пунктом, отличающим Coverity от PVS-Studio является… их рекламный материал.
Как это можно было сделать
Давайте взглянем на типичный отчет о проверке проекта с помощью PVS-Studio. Вот этот попался мне первым на глаза, поэтому я привожу на него ссылку.
Опечатка… Да, вижу. Риск выхода за границу массива… Здесь все ясно. Пара других мелких недочетов… Понятно. Ни малейшего представления как это проблемы могут влиять на работу программы, но о них написано достаточно хорошо и понятно для тех, кому это интересно.
Можно задаться вопросом как вообще программа может работать с этими ошибками.
Все достаточно просто. Дефекты, которые на самом деле себя как-то проявляют были уже обнаружены раньше с помощью других методов — старой доброй отладки программы, юнит тестов, помощи коллег и т. д. Для того, чтобы найти остальные проблемы, требуется больше усилий. Это может быть как-то корявый набор данных. Это может быть какая-то необычная последовательность действий пользователя. Это может быть индикация какой-то специфичной ошибки. Это может обновления компилятора или C++ runtime.
Дефекты есть дефекты. Вы можете сказать «но нельзя же наврать компилятору», однако не все ошибки одинаковые. Эти маленькие детальки могут висеть в базе кода годами и вот однажды, кто-то запускает анализатор PVS-Studio на исходнике и ВОТ ЭТО ДА! У МЕНЯ ЖЕ ТУТ ЦЕЛАЯ КУЧА БАГОВ! ФУГАС МНЕ В ГЛАЗ!
Конечно, сам по себе такой отчет по большому счету бесполезен — необходимо, чтобы был разработчик, который знаком с кодовой базой и мог поправить этот недочет. Отчеты PVS-Studio как раз то, что нужно — они описывают эти недочеты, предоставляя некоторый анализ, ничего лишнего.
Как это делать не надо
Теперь посмотрим на то, как пишет Coverity. Найти такой отчет, похожий на то, что мы только что видели будет очень сложно среди материалов компании Coverity. Но раз в пятилетку ребята из Coverity все же выдают «Integrity Report»
«Integrity Report» это очень красочный документ в котором можно встретить такие слова как «миссия», «безупречно» и «фокус на инновациях». Не плохо для начала — но по крайней мере то, что эти ключевые слова присутствуют в этом документе четко показывают, что на трех первых страницах уже слишком много рекламы.
Переходим к Таблице А… Хмм… эта таблица показывает распределение размеров проектов. Использование слова «distribution» подразумевает, что собранные данные имеют некоторую статистику и заслуживают доверия. Даже проверив, скажем, 45 проектов, пытаться сделать такую таблицу было бы не разумно. У них же всего ДВА проекта и более чем 7 миллионов строк кода. Это просто невероятно, у меня нет слов.
Остальная часть доклада полна таких же абсолютно бессмысленных таблиц. Нет, ну конечно круто, что вы можете найти 9,7654 неполадок на 30 квадратных сантиметров в проекте. Но до тех пор, пока я сам не попробую вашу программу — мне все равно, поскольку эти цифры значат не больше чем показатель 132% эффективности (пост пятилетней давности, но все еще актуален).
Перейдем к Приложению А. Таблицы 2 и 3 суммируют все неполадки, присваивая им категорию и степень значимости. И так, посмотрим…
Проблемы с потоком управления. Это еще что? Это то, когда я забываю поставить «break;» в конце «case» внутри «switch»? Итак, вы говорите, что это средняя степень значимости. Ну ладно. Как насчет того, что функция «main()» возвращает управление сразу же? Это самая настоящая проблема в потоке управления и не говорите, что она всего лишь среднего уровня. Не все проблемы в потоке управления равнозначны.
Разыменование указателя NULL среднего уровня, не так ли? Ну конечно, мой код то тут, то там разыменовывает нулевые указатели и каждый раз, как это случается, пользователям выдается конфетка. Возможно авторы этого Integrity Report имели ввиду разыменовывание потенциально нулевых указателей, когда разыменовывается указатель, не проверяя прежде, равен он нулю или нет. И отличная новость — проверка указателя каждый раз перед тем как он разыменовывается занимает кучу времени. Опять же, не все разыменования нулевых указателей одинаковы.
Проблема в обработке ошибки — средняя степень. Что это? Проверка ошибок кода в функциях Win32 API? Естественно, тот факт, что каждый раз, когда программа хочет открыть файл и просто продолжает чтение, не проверив, удалось открыть или нет, будет для пользователя сущим пустяком. Нет доступа к папке? Давайте притворимся, что мы все-таки сохранили файл. И так сойдет. Не все проблемы обработки ошибок одинаковы.
Проблемы в обработке целых чисел имеют средний уровень значимости. Конечно, переполнение целого числа при вычислении размера распределения памяти вообще ерунда. Просто пусть выделится какое-то количество памяти, а мы сделаем вид, что это корректный размер. Не все проблемы обработки целых чисел одни и те же.
Обработка незащищенных данных имеет средней уровень значимости. Это еще что? Вообще без понятия, но я все же скажу, что не все случаи обработки незащищенных данных схожи.
Некорректное выражение — средняя степень. Конечно, ставьте скобки там, где вам вздумается (где захочет левая пятка), какие проблемы?
Нарушение одновременного доступа — средний уровень. Подумаешь, до конца жизни править эти места потом будешь.
Ошибки использования API — средний уровень. Твой код по ошибке забывает указать путь и из-за этого удаляется все содержание WindowsSystem32. Чихать на это.
Программа висит — средняя степень. Программа зависает только при запуске на компьютере вне домена Windows NT. Ты просто запускаешь ее в своей рабочей сети, потом идешь на торговую выставку и твой ноутбук превращается в обогреватель с монитором за тысячу долларов. Беда какая.
И мне интересно, почему нет категории с низким уровнем? Это из-за того, что авторы не осмелились назвать изъян в программном обеспечении низкого уровня потому что он уже принадлежит какой-то категории?
Так не пойдет. Не получится разбросать несколько тысяч дефектов по нескольким категориям и потом для них назначить уровень значимости. Это просто невозможно. Если вы являетесь разработчиком программного обеспечения вы, вне сомнений, обязаны это понимать. В противном случае — вам стоит сходить в ближайший Макдональдс — у них там есть пункт «Требуется помощь».
В целом Integrity Report — это просто месиво из цифр и диаграмм. Его польза — не то что, ноль, а даже в минус. Такой отчет напугает любого, кто заботится о качестве своих программ.
Итоги
Итак, в чем же разница между рекламными материалами PVS-Studio и Coverity? В том, что первые предоставляют факты, которые можно понять и проверить. А вторые просто пугают своими огромными числами, не предоставляя шанса как-то это проверить.
Потому что не каждый достоин триал версии Coverity.
Автор: PVS-Studio
