Мифы о статическом анализе. Миф пятый – можно составить маленькую программу, чтобы оценить инструмент

Общаясь с людьми на форумах, я заметил несколько стойких заблуждений, касающихся методологии статического анализа. Я решил сделать небольшой цикл статей, в которых попробую показать, как всё обстоит на самом деле.

Миф пятый: "Возможности статического анализатора легко оценить, написав тестовый пример".

Вот как выглядит такое утверждение при обсуждении (собирательный образ):

Я написал специальную программу, размером в 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 пока не работает с утечками памяти.

Зато, он обнаружит такое:

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 на примере обнаруженных ошибок в пяти открытых проектах ".