Народ против PVS-Studio: дубль первый

А зачем PVS-Studio дублировать ошибки, найденные компилятором? Вопрос, конечно же, касается только тех случаев, где VS2010 нашел что-то, а PVS-Studio нет.

Если не видно разницы, зачем платить больше?

Ну и чтоб до кучи, Intel C++ Compiler 12.1.0:
1 тест — ничего
2 тест:

main.cpp(10): remark #1418: external function definition with no prior declaration
  int* prettyFormat(int i, char* buf)
       ^

3 тест: то же, что и второй, плюс

main.cpp(17): warning #592: variable "a" is used before its value is set
      return a;
             ^

4 тест — то же, что и третий.

К слову, Intel C++ Compiler является частью комплекса Intel Parallel Studio XE, linux-версия которого распространяется бесплатно для некоммерческого использования. Не триал. Professional-вариант. Для Linux. Не в пример некоторым компаниям.

По поводу последнего примера с многопоточностью — компилятор или анализатор надо указать каким-то способом, что код будет использоваться параллельно, иначе предупреждениями будет пестрить весь код. К тому же при подобного рода анализе надо учитывать, что сама фнкция может быть потоконебезопасна, но при этом бесопасно использована (локи могут стоять при ее вызовах, к примеру).

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

1. Да, PVS-Studio не находит ошибки, наподобие связанной v.reserve. И ещё долго не будет находить. Это задача колоссальной сложности!!! Чтобы найти ошибку, надо практически виртуально выполнить часть программы, чтобы предположить, что память может быть не выделена. Да ещё вдобавок это шаблонный код. Поставили для спортсмена планку на высоту 3 метра, а потом «Фу… Не перепрыгнул...».
2. Сообщения C4996 вовсе не находят ошибку, а просто ругаются на все sprintf и аналогичные функции. Совершенно непонятно, зачем упомянуты эти предупреждения.
3. По поводу «C4700: uninitialized local variable 'a' used». Да, PVS-Studio не ругается. И в планах особенно нет. Зачем дублировать проверки компилятора?

По поводу гонок – меня статья расстроила. Следует вначале подумать, прежде чем приводить такие примеры. Анализатор теперь должен ругаться на все конструкции работы с глобальными контейнерами или просто переменными? Вдруг этот код начнет выполняться параллельно!

Откуда ему знать про параллельность?

А диагностика, кстати, есть. Мы поддерживаем OpenMP и иногда можем находить ошибки. Вот этот же код, но уже с потоками:

list<unsigned long> a_list;

unsigned long get_next()
{
	unsigned long ret = 0;
	if (!a_list.empty()) {
		ret = a_list.front();
		a_list.pop_front();
	}
	return ret;
}

unsigned long Foo()
{
  unsigned long S = 0;
  #pragma omp parallel for reduction(+:S)
  for (int i = 0; i < 10; i++)
    S += get_next();
  return S;
}

Диагностика PVS-Studio:

V1207 Data race risk. The 'a_list' object can be changed concurrently by a non-const function. GeneralPurposeErrors test.cpp 82

С обыкновенными потоками мы работать не умеем и не хотим. Это неблагодарная работа. Для этого есть инструменты динамического анализа. Или можно взять PC-Lint. Он это умеет. Только не надо фантазий, что он сам про потомки догадается. Для выявления параллельных ошибок код должен быть размечен специальным образом. Подробнее про это я писал в статье: “Что такое «Parallel Lint»?”

За статью спасибо. Мы всегда рады замечаниям и пожеланиям и стараемся их реализовывать. Но мне не понравилась бессмысленность критики. Я не увидел здесь никакого сравнения.

Адекватное сравнение может быть только на реальных проектах. Взяли проект A. Проверили его с помощью PC-Lint / VisualC++ / PVS-Studio / C++Test. Внимательно проанализировали все сообщения. Составили табличку, какой анализатор сколько ошибок нашел. Вот единственное настоящее сравнение.

Беда в том, что это очень большой объем работы и даже мы не можем найти время этим позаниматься. Примером подобной статьи, может служить вот это “Проверка пяти открытых проектов статическими анализаторами общего назначения”.

Расскажу о своём опыте тестирования PVS-Studio. Скачал, поставил, взял проект на 500к строк кода, запустил. Нашло пару сот ворнингов. Беру первый — ложное срабатываение, второй-тоже. В общем, после где-то 30-го ложного срабатывания, так и не найдя ни одного реального бага я плюнул и удалил PVS. Не знаю, может быть случайность, но что было, то было.

По существу статьи коллега уже высказался. Отмечу лишь, что с сравнивать инструменты нужно более комплексно. Например, если разработчики в субботу обеспечивают поддержку — то это, наверное, дополнительный плюс в копилку?