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

Попробовав Klocwork, я попытался заинтересовать в нем руководство, однако цена в 30 тыс. евро послужила главным останавливающим критерием, все остальное было уже не важно.

Однако кто-то вдруг вспомнил, что однажды компания уже приобретала лицензию на какой-то анализатор кода. Этим анализатором оказался PC-Lint. Оказалось, что его никто не использует (дочитав до конца, поймете, почему), так что лицензию отдали мне, мол, играйся, если интересно.

Не успел я поделиться впечатлениями от PVS-Studio, как сразу же последовали обвинения в рекламе. Что ж, расскажу о своем первом опыте использования систем static code analysis.

Так получилось, что первой системой, с которой я столкнулся, стал Klocwork. Это произошло лет 8-9 назад, когда я работал в украинском филиале одной словенской компании. Тогда анализатор запускался в головном офисе, мы же лишь получали экспортированные в эксель результаты. Но даже в таком виде, помнится, меня приятно удивляло то, насколько хорошо находились потенциальные (а порой и реальные) проблемы.

И вот (уже тоже в далеком 2010 году), увидев на Embedded World стенд того самого Klocwork-a, подошел порасспрашивать их насчет триал-лицензии для «попробовать». Спустя какое-то время получил от них е-мейл с вопросом: «Вы интересовались, все еще хотите?».

Интерес к статическим анализаторам кода у меня уже давно, с первого знакомства с Klocwork где-то лет шесть назад. Кроме него, довелось некоторое время поработать с PCLint. И вот теперь немного потестировал PVS-Studio. (А на очереди – Parasoft и Coverity).

Тестирование я провел исключительно из любви к искусству – интересно было попробовать еще один анализатор.

«Самой важной вещью, которую я сделал как программист за последние годы — это начал агрессивно применять статический анализ кода. — пишет Джон Кармак в статье, опубликованной на AltDevBlogADay. — Не так важны сотни серьёзных багов, которые удалось предотвратить, сколько смена ментальности и моего отношения к надёжности ПО и качеству кода».

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

Прогресс не стоит на месте. Развивается и мой любимый статический анализатор кода PVS-Studio. И недавно я понял, что те проекты, которые мы уже проверяли, можно вполне проверять заново. Писать про это новые статьи как-то странно и вряд ли они получатся интересными. Однако одну такую статью я всё-таки думаю надо сделать. Она станет еще одним аргументом в пользу утверждения, что настоящую пользу от статического анализа можно получить только при его регулярном использовании, а не при проверках от случая к случаю. Итак, посмотрим, что же удалось найти нового интересного в проекте Intel IPP Samples.

Добрый вечер Хабранарод!

Воодушевленный этим постом и Хабрасообществом, предлагаю вам свой вариант анализа хорошо пропиаренной утилиты (как примечательно выразился Wo1f) — PVS-Studio.

В качестве примечания, использовал Visual Studio 2010 (крэкнутый, конечно) и скачал PVS-Studio из официального сайта, нажимая «Download and Try» и следуя инструкциям. Все это я пишу потому, что у меня вопросы на счет данной утилиты и требуется ваша, так сказать, помощь.

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

Тест 1:

int main()
{
	vector<int> v;
	v.reserve(2);
	assert(v.capacity() == 2);
	v[0];
	v[0] = 1;
	v[1] = 2;
	cout << v[0] << endl;
	v.reserve(100);
	cout << v[0] << endl;
	return 0;
}

VS2010: ничего
PVS-Studio: ничего

Анализ следующих утилит:

• RATS (Rough Auditing Tool for Security)
• Cppcheck
• Graudit

Все необходимое можно найти пройдя по ссылкам, а мы сразу перейдем к делу.

Тест 1:

int main()
{
	vector<int> v;
	v.reserve(2);
	assert(v.capacity() == 2);
	v[0];
	v[0] = 1;
	v[1] = 2;
	cout << v[0] << endl;
	v.reserve(100);
	cout << v[0] << endl;
	return 0;
}

Введение

Долгое время считалось, что динамический анализ программ является слишком тяжеловесным подходом к обнаружению программных дефектов, и полученные результаты не оправдывают затраченных усилий и ресурсов. Однако, две важные тенденции развития современной индустрии производства программного обеспечения позволяют по-новому взглянуть на эту проблему. С одной стороны, при постоянном увеличении объема и сложности ПО любые автоматические средства обнаружения ошибок и контроля качества могут оказаться полезными и востребованными. С другой – непрерывный рост производительности современных вычислительных систем позволяет эффективно решать все более сложные вычислительные задачи. Последние исследовательские работы в области динамического анализа такие, как SAGE, KLEE и Avalanche, демонстрируют, что несмотря на присущую этому подходу сложность, его использование оправдано, по крайней мере, для некоторого класса программ.

Как-то раз сидел в аудитории с ноутом около розетки, а в это время на соседней парте принимался зачет по программированию. Я не сильно вникал в суть вопросов на которые общались студент и преподаватель, назовем его Иван Ивановичем. Разговор был довольно спокойный и тихий, но у меня получилось выхватить часть. Преподаватель говорил о комментариях (видимо сдавалась программа, в которой не было ни строчки комментариев). Меня этот момент заинтересовал и я начал прислушиваться. Было замечено, что мне тоже интересно, преподаватель начал импровизированную лекцию. Ниже представлен тот небольшой кусок знаний который я тогда вынес с этой 5ти минутной лекции.

В последнее время, рассказывая о проверке очередного проекта, я всё время повторял, что это очень качественный код и ошибок в нём практически не найдено. Примером может служить анализ таких проектов, как Apache, MySQL, Chromium. Почему мы выбираем такие приложения, я думаю понятно. Про них всех знают и никому не интересно, какие ужасы можно найти в дипломной работе студента Васи. Однако иногда мы поверяем и те проекты, которые просто случайно попали под руку. Некоторые такие проекты оставляют тяжёлые впечатления в моей тонкой и ранимой душе. В этот раз мы проверили Intel® Energy Checker SDK (IEC SDK).