Общаясь с людьми на форумах, я заметил несколько стойких заблуждений, касающихся методологии статического анализа. Я решил сделать небольшой цикл статей, в которых попробую показать, как всё обстоит на самом деле.
Миф пятый: "Возможности статического анализатора легко оценить, написав тестовый пример".
Вот как выглядит такое утверждение при обсуждении (собирательный образ):
Я написал специальную программу, размером в 100 строк кода. Но анализатор ничего мне не выдает, хотя у меня включены все уровни предупреждений. Глупость этот ваш [инструмент] / [статический анализ] в целом.
Глупостью является не методология статического анализа, а такой подход к попытке оценить пользу от использования конкретного инструмента. Некорректность исследования инструмента складывается из двух моментов:
1.
Программисты думают, что не допускают простых ошибок. Этот феномен был рассмотрен в Мифе номер 2. Поэтому они стараются подсунуть анализатору хитрый пример и втайне радуются, если анализатор не смог найти ошибку. Эта игра интересна, но не имеет практического смысла.
Надо осознавать, что большинство ошибок до безобразия просты. И статические анализаторы хорошо их диагностируют. Парадокс в том, что придумать простую ошибку намного сложнее, чем сложную. Вот смотрите сами. Вы сможете догадаться составить вот такой пример?
int threadcounts[] = { 1, kNumThreads };
for (size_t i = 0;
i < sizeof(threadcounts) / sizeof(threadcounts); i++) {
Сомневаюсь. Невозможно представить, что можно сделать такую тупую ошибку и написать "sizeof(threadcounts) / sizeof(threadcounts)". Соответственно, такой пример никогда составлен не будет. А, между прочим, этот код не из лабораторной работы студента, а из проекта Chromium. И конечно, он прекрасно диагностируется анализатором PVS-Studio.
2.
Составленные примеры носят случайный характер. Причем примеров мало. Поэтому получается, что в зависимости от удачи можно получить разнообразнейший результат. Можно придумать 5 ошибок, которые будут успешно найдены первым анализатором, и не обнаружены вторым. А можно придумать программу с пятью ошибками, на которых анализаторы покажут противоположные результаты. Выборка для исследования слишком мала. Чтобы хоть как-то сравнивать и изучать, нужно придумать текст программы, где имеется хотя бы 500 разных ошибок. Исследования на примерах с 5-10 ошибками ничего не дают.
Вдобавок, программисты ожидают увидеть диагностику определенного типа ошибок, забывая о других. Например, практически все пишут один и тот же пример, где не освобождается память:
void Foo()
{
int *a = (int *)malloc(X);
int *b = (int *)malloc(Y);
//...
free(a);
}
Какие-то анализаторы диагностируют эту ошибку, какие-то нет. Например, PVS-Studio пока не работает с утечками памяти.
Привет из 2017 года. Всё давно изменилось. Приглашаем познакомиться со статьёй "Да, PVS-Studio умеет выявлять утечки памяти".
Зато, он обнаружит такое:
static int rr_cmp(uchar *a,uchar *b)
{
if (a[0] != b[0])
return (int) a[0] - (int) b[0];
if (a[1] != b[1])
return (int) a[1] - (int) b[1];
if (a[2] != b[2])
return (int) a[2] - (int) b[2];
if (a[3] != b[3])
return (int) a[3] - (int) b[3];
if (a[4] != b[4])
return (int) a[4] - (int) b[4];
if (a[5] != b[5])
return (int) a[1] - (int) b[5];
if (a[6] != b[6])
return (int) a[6] - (int) b[6];
return (int) a[7] - (int) b[7];
}
Здесь вместо "return (int) a[1] - (int) b[5];" должно быть "return (int) a[5] - (int) b[5];".
Почему никто никогда не составляет подобные примеры? А ведь эту ошибку PVS-Studio нашел в проекте MySQL.
Вывод. Адекватное исследование или сравнение инструментов может быть только на реальных проектах. Взяли проект A. Проверили его с помощью PC-Lint / Visual C++ / PVS-Studio / C++Test. Внимательно проанализировали все сообщения. Составили табличку, какой анализатор сколько ошибок нашел. Вот единственное настоящее изучение и сравнение. Пример: "Сравнение статического анализа общего назначения из Visual Studio 2010 и PVS-Studio на примере обнаруженных ошибок в пяти открытых проектах ".
0