Как мы сравнивали анализаторы кода CppCat, Cppcheck, PVS-Studio, Visual Studio

Андрей Карпов
Статей: 372



К сожалению, мы больше не развиваем и не поддерживаем проект CppCat. Вы можете почитать здесь о причинах.

Мы провели подробное сравнение четырёх анализаторов Си/Си++ кода: CppCat, Cppcheck, PVS-Studio и статический анализатор, встроенный в Visual Studio. В этой статье подробно рассматриваются методика сравнения анализаторов и полученные результаты.

Picture 2

Введение

Мы неоднократно писали [1, 2], что сравнение статических анализаторов является сложной задачей. Для этого не подходит посчитать количество диагностических правил, описанных в документации. Не имеет смысла считать количество сообщений, выдаваемых анализаторами на тестовом проекте. Единственный адекватный метод - это проверка различных проектов и сравнение количества найденных в нём ошибок. Это очень большая и трудоемкая задача. Но только она позволяет по-настоящему сравнить анализаторы.

Хочется отметить, что нами был проделан большой объем работы. Над сравнением работало 4 человека. Суммарно было потрачено 170 человеко-часов. Это более месяца работы одного программиста!

Трудоёмкость сравнения

Почему потребовалось 170 часов? Многие моменты не заметны, скучны, но требуют времени. Например, в отчёт не попали результаты проверки проекта Steamworks SDK. В нем анализаторы PVS-Studio и CppCat нашли одну единственную ошибку. Остальные анализаторы вообще ничего не нашли. Этот проект нет смысла включать в сравнение, но на поиск, скачивание и анализ этого проекта было потрачено время. Ещё пример. Неоднократно анализатор, встроенный в Visual Studio, вызывал падение среды, и приходилось перезапускать анализ. Из таких мелочей и складывается большой объем работ.

Вот как выглядит трудоемкость отдельных этапов сравнения:

  • 40 часов. Подбор проектов. Настройка окружения для того, чтобы проекты можно было скомпилировать и проверять (скачивание сторонних библиотек и так далее).
  • 10 часов. Проверка проектов различными анализаторами.
  • 70 часов. Изучение диагностических сообщений и выписывание интересных примеров.
  • 10 часов. Размышления, как лучше представить данные, разработка структур Excel-таблиц.
  • 15 часов. Оформление полученных результатов в Excel-таблицах.
  • 5 часов. Составление сводных таблиц и создание соответствующих рисунков для статей.
  • 20 часов. Написание, оформление и публикация статей.

Сравниваемые анализаторы

Проводилось сравнение следующих анализаторов:

  • CppCat 1.1;
  • Cppcheck 1.63.1;
  • PVS-Studio 5.13;
  • Встроенный статический анализатор в Microsoft Visual Studio Professional 2013.

Каждый анализатор использовался в оптимальном режиме:

  • CppCat: уровни диагностик отсутствуют;
  • Cppcheck: важные предупреждения (Errors и Warnings);
  • PVS-Studio: рекомендуемые настройки (1 и 2 уровень предупреждений общего назначения);
  • Visual Studio 2013: Microsoft Native Recommended Rules.

Какие проекты были проверены

Были проверены следующие open-source проекты:

  • Eigen is a high-level C++ library of template headers for linear algebra, matrix and vector operations, numerical solvers and related algorithms;
  • PostgreSQL, often simply "Postgres", is an open-source object-relational database management system (ORDBMS) with an emphasis on extensibility and standards-compliance;
  • Source SDK. The Source SDK is a software development kit compiled by Valve Corporation that is used to create games or mods for the Source engine;
  • Synergy is a software application for sharing a keyboard and mouse between multiple computers.
  • Coin3D is a free and open-source implementation (library) of the Open Inventor API;
  • OpenDDS. The Data Distribution Service for Real-Time Systems (DDS) is an Object Management Group (OMG) machine to machine middleware "m2m" standard that aims to enable scalable, real-time, dependable, high performance and interoperable data exchanges between publishers and subscribers;
  • Firebird is an open source SQL relational database management system that runs on Linux, Windows, and a variety of Unix;
  • CRYENGINE SDK, originally called Sandbox Editor, is the current version of the level editor used to create levels for CryEngine by Crytek;
  • FlightGear Flight Simulator (often shortened to FlightGear or FGFS) is a free, open source multi-platform flight simulator developed by the FlightGear project since 1997;
  • V8 implements ECMAScript as specified in ECMA-262, 5th edition, and runs on Windows (XP or newer), Mac OS X (10.5 or newer), and Linux systems that use IA-32, x64, or ARM processors;
  • Wild Magic 5. C++ library for real-time computer graphics and physics, mathematics, geometry, numerical analysis, and image analysis;
  • Rhino is an open source JavaScript engine. It is developed entirely in Java and managed by the Mozilla Foundation. It is separate from the SpiderMonkey engine, which is also developed by Mozilla, but is written in C and is used in Firefox;
  • Push Framework is an open source C++ Toolkit for high-performance server development.

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

Поэтому авторам проектов, которые заинтересовались этой статьёй, мы предлагаем провести проверку самостоятельно, для наиболее свежей версии кода.

Также отметим, что не делалось различий, относятся предупреждения к самим проектам или к используемым внутри них сторонних библиотекам. Это не имеет значения с точки зрения сравнения.

Как происходил отбор предупреждений

Это очень непростой вопрос. Предупреждения анализатора предлагают внимательно изучить определённые места в коде. Хотя, часто это не ошибки, такие места заслуживают внимания. Полезно повести рефакторинг таких мест, чтобы они стали более понятны не только анализатору, но и коллегам.

Тем не менее, хочется сравнить именно количество ошибок или мест, которые могут привести к ошибке со временем.

Здесь очень сложно провести грань. Мы не можем дать формального определения, что мы считаем по настоящему опасным фрагментом кода в программе. Нам пришлось руководствоваться интуицией. Надеемся, она нас не подвела.

Приведу пример тонкой грани.

Есть диагностики, которые предупреждают, что функция использует много стековой памяти, например, 16 килобайт (по умолчанию размер стека программы равен 2 мегабайтам). Такое бывает, если в функции объявить локальный массив "double x[2000]". Ошибка или нет? Такие функции встречаются весьма часто в программах и, как правило, не приводят к проблемам. Мы решили считать предупреждения о наличии таких функций не интересными.

Другое предупреждение: вызов в цикле такой функции, как alloca(). Функция alloca() выделяет память в стеке. Она удобна тем, что память не надо специально освобождать. Однако, если её использовать в цикле, она может быстро израсходовать весь стек. Произойдёт это или нет, неизвестно. На наш взгляд, такая конструкция более опасна, чем разовое выделение стека при входе в функцию. И мы выпишем соответствующие диагностические сообщения.

Мы старались придерживаться следующего принципа:

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

Рассмотрим несколько случаев, чтобы было понятней, какие фрагменты кода мы посчитали опасными, а какие нет.

Пример явной ошибки:

if (memcmp(&(beentry->st_clientaddr), &zero_clientaddr,
           sizeof(zero_clientaddr) == 0)) 

Не там поставлена скобка. В результате функция memcmp() сравнивает 0 байт.

Пример потенциальной ошибки:

const ULONG END_BUCKET = (~0) << 1;

Сдвиг отрицательного значения приводит к неопределённому поведению. Этот код может давать на некоторых компиляторах тот результат, который ожидает программист. Но это только везение. В любой момент код может отказать. Мы считаем такие предупреждения интересными и полезными.

Пример кода, который мы решили не выписывать:

size_t length = ....;
fb_assert(ptr && length >= 0 && length < 9);

Переменная 'lenght' имеет беззнаковый тип. Формально, сравнение "length >= 0" не имеет практического смысла и является лишним. Мы считаем подобные предупреждения неинтересными.

Ложные срабатывания

Изначально, мы хотели указать количество ложных срабатываний. Но если просто выписывать общее количество предупреждений, которые выдают анализаторы, то у читателя возникнет неправильное представление. На некоторых проектах отдельные анализаторы выдают просто огромное количество ложных предупреждений, которые, на самом деле, легко устранить.

Нет, мы не стараемся представить в лучшем свете PVS-Studio или CppCat. Они хорошо показали себя. Плохие результаты показал Visual Studio.

Во всех анализаторах есть следующий механизм, сокращающий число предупреждений. Если подозрительный код находится в *.h файле, то сообщение выдаётся только один раз, независимо от того, сколько раз этот заголовочный файл включается в *.cpp файлы. Нет смысла вновь и вновь рассматривать одно и то же предупреждение. Есть этот механизм и в статическом анализаторе, встроенном в Visual Studio.

Беда в том, что в Visual Studio этот механизм работает только в рамкам проекта, а не всего проверяемого решения (solution). В результате, при проверке некоторых проектов можно наблюдать следующую картину.

Решение (solution) Eigen содержит в себе более 500 проектов. При этом имеется несколько заголовочных файлов, используемых во всех этих проектах. Эти заголовочные файлы содержат подозрительные фрагменты кода, на которые Visual Studio выдаёт предупреждения. Поскольку фильтрация сообщений осуществляется только в рамках отдельного проекта, то каждое предупреждение всё равно дублируется около 500 раз.

В результате получается, что вместо 3 более-менее полезных сообщений в злосчастных заголовочных *.h файлах, генерируется около 1900 предупреждений.

Такие негативные результаты приводить не хочется. Ситуацию легко исправить, модифицировав заголовочные файлы. Но здесь мы сталкиваемся с дилеммой. Нечестно уделить внимание одному инструменту, но ничего не сделать по отношению к другим.

Ведь характеристики CppCat, Cppcheck и PVS-Studio тоже можно существенно улучшить, проведя минимальную настройку. Например, PVS-Studio иногда выдаёт предупреждение везде, где встречается подозрительный макрос. В качестве примера, сошлюсь на статью "Третья проверка кода проекта Chromium". В ней описывается случай, когда отключение предупреждений для макроса DVLOG сразу устранило 2300 ложных предупреждений.

Та же самая ситуация и с анализатором Cppcheck. Получается, что минимальная настройка даст существенное улучшение показателей.

Можно сделать полезный вывод:

Нельзя говорить о количестве ложных предупреждений, не проведя минимальной настройки статических анализаторов кода. Из-за досадных мелочей можно получить картину намного хуже, чем она есть на самом деле.

Итак, мы сделали вывод, что нужна минимальная настройка. Но мы не знаем, как одинаково уделить внимание всем анализаторам. Всегда можно сказать, что одному мы уделили больше времени на настройку, чем остальным. Мы решили вообще отказаться от характеристики "количество ложных срабатываний".

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

Предвзятость при оценке

Мы старались быть непредвзятыми. Полностью это невозможно. Сложно быть авторами какого-то инструмента, и беспристрастно сравнивать его с другими.

Но поверьте, что мы старались сделать честное сравнение. Плюс, CppCat и PVS-Studio нашли гораздо больше ошибок, поэтому нам нет смысла специально завышать для них оценки.

В чем могла проявиться предвзятость

Мы лучше знаем наши анализаторы CppCat и PVS-Studio. Поэтому мы можем быстрее и легче понять, что найдена ошибка. При работе с другими анализаторами больше вероятность, что мы могли что-то пропустить.

Компенсация

Понимая, что мы можем что-то пропустить из сообщений, выданных другими анализаторами, мы старались это компенсироваться. Приведём пример. Мы не считаем следующую ошибку существенной:

unsigned int x = ....;
printf("%d", x);

Вместо "%d" следует использовать "%u", Беда будет в том случае, если алгоритм работает с большими числами (больше INT_MAX). Но на практике такой код почти никогда не приводит к проблемам. Поэтому PVS-Studio выдаёт предупреждение 3-его уровня, которое не попало в отчёт.

На наш взгляд, можно было не выписывать это сообщение и в том случае, если его выдают другие анализаторы. Однако, Cppcheck считает эту ошибку существенной. Мы выписывали такие предупреждения для этого анализатора, хотя для PVS-Studio такие записи отсутствуют.

Мы надеемся, что такая компенсация позволила в среднем честно сравнить все анализаторы.

Скорость работы анализаторов

Неожиданно для себя мы поняли, что параметр "скорость работы" совершенно бессмысленный, если он оторван от конкретного проекта. В зависимости от проекта, скорость работы анализаторов может существенно отличаться.

Хорошо это можно продемонстрировать следующими примерами:

  • проект PostgreSQL анализатор PVS-Studio проверят 8 минут, а Cppcheck всего 1 минуту;
  • проект Synergy анализатор PVS-Studio проверят 1 минуту, а Cppcheck - 7 минут.

Колоссальный разброс. На одном проекте анализатор Cppcheck работает в 8 раз быстрее, чем PVS-Studio. На другом, наоборот, PVS-Studio оказался в 7 раз быстрее анализатора Cppcheck.

Конечно, можно посчитать некоторое среднее значение. И мы это сделаем.

Но следует понимать, что программист работает не с абстрактным "средним" кодом, а со своим конкретным проектом. И невозможно предсказать, какой из анализаторов будет быстрее выполнять проверку. Имейте это в виду.

Время, за которое выполняется анализ различных проектов:

Таблица 1 – Время выполнения анализа для различных проектов (в минутах)

Таблица 1 – Время выполнения анализа для различных проектов (в минутах)

В среднем, самым быстрым анализатором оказался Cppcheck. Хуже всего показал себя статический анализ, реализованный в Visual Studio. CppCat работает на самом деле чуть-чуть быстрее, чем PVS-Studio, так как осуществляет меньше проверок. Но разница столь незначительна (десятки секунд), что отмечать это в таблице нет смысла.

Процесс проверки и анализа результатов

Проекты были проверены без особых сложностей. Самой сложной задачей оказалось просмотреть диагностические сообщения и выбрать интересные.

К сожалению, на некоторых проектах не удавалось просмотреть все сообщения какого-то типа. Если десятки сообщений оказывались ложными, группа этих сообщений дальше не изучалась. Да, таким образом мы что-то могли пропустить. Но тратить время и внимательно просмотреть все-все-все диагностики, мы не можем себе позволить. Поскольку в роли "неудачников" выступали разные анализаторы, в среднем это не должно повлиять на качество сравнения.

Приведу для ясности пример, когда мы останавливали просмотр сообщений.

На одном из проектов Visual Studio выдал более 500 предупреждений следующего типа:

C6011 Dereferencing NULL pointer 'obj'. test_cppbind  
    ghost.hxx  714
    'obj' may be NULL (Enter this branch)      705
    'obj' is dereferenced, but may still be NULL      714

Выберем функцию попроще и изучим причину возникновения этого сообщения:

static raw_type& requireObject(naContext c, naRef me)
{
  raw_type* obj = getRawPtr( fromNasal(c, me) );
  naGhostType* ghost_type = naGhost_type(me);
  if( !obj )
    naRuntimeError
    (
      c,
      "method called on object of wrong type: "
      "is '%s' expected '%s'",
      ghost_type ? ghost_type->name : "unknown",
      _ghost_type.name
    );
  return *obj;
}

На самом деле, беды нет. Давайте заглянем внутрь функции naRuntimeError():

void naRuntimeError(naContext c, const char* fmt, ...)
{
    va_list ap;
    va_start(ap, fmt);
    vsnprintf(c->error, sizeof(c->error), fmt, ap);
    va_end(ap);
    longjmp(c->jumpHandle, 1);
}

Функция распечатывает сообщение об ошибке и вызывает функцию longjmp. Это альтернатива механизму исключений.

Нам важно то, что функция naRuntimeError() не возвращает управление. Разыменование нулевого указателя никогда не произойдёт. Анализатор Visual Studio не может во всём этом разобраться и выдаёт множество ложных предупреждений.

Просмотрев первые 20 сообщений, мы везде встретили одно и то же ложное срабатывание, связанное с вызовом функции naRuntimeError(). И мы прекратили просмотр диагностических сообщений с кодом C6011 (Dereferencing null pointer).

Могли мы пропустить что-то полезное, среди оставшихся 500 сообщений об разыменовании нулевого указателя? Да могли. Но тратить многие часы времени, чтобы понять, что все 500 предупреждений ложные, тоже не хочется. В том примере, что приведён в статье, сразу понятно, что ошибки нет. Анализ же больших функций крайне трудоёмок.

Ещё раз повторюсь, что мы не считаем это проблемой. Мы пропускали некоторые группы сообщений у всех анализаторов. Иногда плохие предупреждения выдавал Visual Studio, иногда Cppcheck, иногда PVS-Studio или CppCat. В среднем, мы думаем пропуски некоторых диагностик компенсируют друг друга.

Итоговая таблица

Наконец мы добрались до результатов, которые представим в виде сводной таблицы:

Таблица 2 – Сравнение диагностических возможностей различных анализаторов. Нажмите на картинку для увеличения.

Таблица 2 – Сравнение диагностических возможностей различных анализаторов. Нажмите на картинку для увеличения.

Таблица в Excel была получена следующим образом. Мы выписали на каждую отдельную страницу книги Excel сообщения, относящиеся к каждому из анализаторов. Получилось четыре таблицы. Затем все эти таблицы вручную были объединены в таблицу с заголовком "CppCat + PVS-Studio + Cppcheck + Visual Studio (including duplicate messages)". Разумеется, простое объединение таблиц дает дубликаты, которые средствами Excel были устранены. Так получилась пятая таблица с заголовком "CppCat + PVS-Studio + Cppcheck + Visual Studio (without duplicate messages)". Уже по этой таблице строились итоговые таблицы по каждому проверяемому проекту для всех четырех анализаторов. Итоговые таблицы для всех проверенных проектов сведены в одну сводную таблицу, которую вы и видите сейчас – это таблица 2.

Сводная таблица (таблица 2) содержит следующую информацию:

  • список проверенных проектов;
  • суммарное количество найденных реальных ошибок в этом проекте для всех анализаторов;
  • количество реальных ошибок, найденных каждым анализатором в виде числа и в виде процента;
  • зеленым цветом выделен анализатор, показавший лучший результат в данном проекте;
  • В графе total показана суммарная информация по всем проектам.

Вы можете скачать этот Excel файл со всеми обнаруженными ошибками здесь: SCA_Comparison.xlsx.

Отличие PVS-Studio от CppCat

В статье не видно отличий между PVS-Studio и CppCat. Дело в том, что работа PVS-Studio на рекомендуемых настройках, ничем не отличается от работы CppCat.

Подробнее, чем отличается CppCat от PVS-Studio описано в статье "Альтернатива PVS-Studio за $250".

Есть ли ошибки, которые были найдены с помощью PVS-Studio и которые не обнаруживаются с помощь CppCat? Да, есть. Например, третий уровень предупреждений общего назначения, выявил ряд ошибок. Приводим их просто в качестве справочной информации: PVS_Studio_Level3.txt. Всего выписано 52 полезных предупреждения третьего уровня.

Внимательно третий уровень предупреждений мы не изучали, и могли что-то пропустить. Диагностические сообщения, относящиеся к 64-битным ошибкам и микрооптимизациям, не рассматривались совсем.

Субъективная оценка анализаторов

Будет некрасиво хвалить свои собственные анализаторы CppCat и PVS-Studio. Отметим только, что они обнаружили наибольшее количество дефектов, при умеренном количестве ложных срабатываний.

Если говорить о Cppcheck и Visual Studio, то мы однозначно отдаём предпочтение Cppcheck. Анализатор в Visual Studio как минимум не доработан. Мы неоднократно наблюли падение Visual Studio при просмотре диагностических сообщений. После нажатия мышкой на очередное диагностическое сообщение среда аварийно завершает работу. Если к этому добавить, что анализ в Visual Studio не позволяет сохранить отчёт по окончанию проверки, то такие падения крайне раздражают. Приходится вновь перепроверять проект.

Также диагностические сообщения Cppcheck, на наш взгляд, намного более понятны, чем сообщения Visual Studio. Стоит отметить, что анализатор в Visual Studio раскрашивает код при выборе сообщения в списке. На наш взгляд, для средних и больших функций эта раскраска ничем не помогает. Понять же причину из сообщения бывает достаточно сложно.

Заключение

Как видите, сравнения статических анализаторов - сложная комплексная задача. Мы думаем, что подошли к ней серьезно и предоставили адекватные результаты сравнения. Надеемся, они окажутся полезными и интересными всем, кто интересуется тематикой статического анализа.

Дополнительные ссылки на наши старые статьи по теме сравнения анализаторов кода



Найдите ошибки в своем C, C++, C# и Java коде

Предлагаем попробовать проверить код вашего проекта с помощью анализатора кода PVS-Studio. Одна найденная в нём ошибка скажет вам о пользе методологии статического анализа кода больше, чем десяток статей.

goto PVS-Studio;


Найденные ошибки

Проверено проектов
346
Собрано ошибок
13 124

А ты совершаешь ошибки в коде?

Проверь с помощью
PVS-Studio

Статический анализ
кода для C, C++, C#
и Java

goto PVS-Studio;