Неоднократно нам задавали вопрос, как сильно пересекаются диагностики нашего анализатора PVS-Studio и анализатора Cppcheck. Я решил написать маленькую статью на эту тему, чтобы быстро отвечать на этот вопрос. Если совсем коротко — то пересекаются слабо. Только 6% от общего количества ошибок находятся обоими анализаторами. В статье будет рассказано как было получено это число.

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

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

В случае с компиляторами и интерпретаторами к исходному коду и тестированию, как правило, предъявляются повышенные требования качества и надёжности. Тем не менее, в исходном коде интерпретатора PHP нашлись подозрительные места.

В данной статье будут рассмотрены результаты проверки интерпретатора PHP, полученные с помощью PVS-Studio 5.18.

Asterisk — свободное решение компьютерной телефонии с открытым исходным кодом от компании Digium. Приложение работает на таких операционных системах, как Linux, FreeBSD, OpenBSD, Solaris. Asterisk в комплексе с необходимым оборудованием обладает всеми возможностями классической АТС, поддерживает множество VoIP-протоколов и предоставляет богатые функции управления звонками.

В данной статье будут рассмотрены результаты проверки Asterisk, полученные с помощью PVS-Studio 5.18.

Проект, по всей видимости, проверяется анализатором Coverity, о чём свидетельствуют комментарии вида:

/* Ignore check_return warning from Coverity for ast_exists_extension below */

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

Cocos2d — открытое программное обеспечение, фреймворк. Он может быть использован для построения игр, приложений и графических интерфейсов интерактивных кроссплатформенных приложений. Cocos2d содержит множество бранчей, известные из них Cocos2d-iPhone, Cocos2d-x, Cocos2d-html5 и Cocos2d-XNA

В данной статье будут рассмотрены результаты проверки Cocos2d-x, фреймворка для C++, полученные с помощью PVS-Studio 5.18. Проект достаточно качественный, но всё же на некоторые места стоит обратить внимание. Исходный код взят с GitHub.

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

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

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

Чтобы проверить GIMP, для начала нужно научиться его компилировать. Это непростая задача, из-за которой поверка несколько раз откладывалась. Однако, проект известный, и интересно оценить качество исходного кода. Поэтому лень была побеждена, и проект проанализирован.

В статье хочу рассказать о проверке проекта Wine такими статическими анализаторами C/C++ кода, как PVS-Studio и Clang Static Analyzer.

Сейчас любое крупное приложение состоит из множества сторонних библиотек. Хочется поднять такую тему, как доверие к этим библиотекам. В книгах и статьях можно встретить очень много рассуждений о качестве кода, методах тестирования, методологиях разработки и так далее. Но я не помню, чтобы кто-то рассуждал о качестве кирпичей, из которых строятся приложения. Давайте немного поговорим об этом. Например, есть Medicine Insight Segmentation and Registration Toolkit (ITK). Мне кажется, он написан весьма качественно. По крайней мере, я заметил в коде весьма мало ошибок. Но я не могу сказать, что код используемых библиотек столь же качественен. Тогда вопрос. Насколько мы можем доверять таким системам? Есть повод для размышлений.

Да, да. Вы не ослышались. В этот раз статья «наоборот». Не мы проверяем какой-то проект, а проверили наш анализатор с помощью другого инструмента. На самом деле, подобное делали мы и раньше. Например, проверяли PVS-Studio с помощью Cppcheck, с помощью анализатора, встроенного в Visual Studio, смотрели на предупреждения Intel C++. Но раньше не было повода написать статью. Ничего интересного не находилось. А вот Clang смог заинтересовать своими диагностическими сообщениями.

Помните какой шум поднялся, когда в Visual Studio 2012 меню стало выглядеть так, как будто у разработчиков Visual Studio заело Caps Lock? Веселись, народ! Проблему починили. В Visual Studio «14» CTP2 как и в Visual Studio 2013 Update 3 RC меню будет выглядеть традиционно.

Ничего эпического в этой статье не будет. Мы проверили с помощью PVS-Studio исходный код Bitcoin. Нашли всего пару подозрительных мест. Это не удивительно. Думаю, эти исходные коды не проверял только ленивый. Но раз проверили, то решил написать маленькую заметку. Так сказать, «для галочки».

Статья рассчитана на людей, которые знакомятся со средой Visual Studio и пытаются компилировать в ней свои Си++-проекты. В незнакомой среде всё кажется странным и непонятным. Особенно новичков раздражает файл stdafx.h, из-за которого возникают странные ошибки во время компиляции. Очень часто всё заканчивается тем, что новичок долгое время везде старательно отключает Precompiled Headers. Чтобы помочь людям разобраться что к чему, и была написана эта статья.

Как вы знаете, основная наша деятельность – это разработка анализатора кода PVS-Studio. И хотя мы давно и, как нам кажется, успешно этим занимаемся, недавно у нас появилась необычная мысль. Все-таки мы не пользуемся своим инструментам в том режиме, что и наши клиенты. Нет, конечно, мы проверяем код PVS-Studio с помощью PVS-Studio. Но откровенно говоря, проект PVS-Studio не такой уж большой. И работа с кодом PVS-Studio по стилю и характеру отличается от, к примеру, работы с кодом Chromium или LLVM.

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

Ну да ладно, к чему это все? Наши теоретические желания попробовать себя в других проектах совпали с практическими предложениями, которые постепенно стали к нам поступать. В прошлом году мы решили выделить у нас в компании команду, которая бы занималась – о ужас! – разработкой на заказ. То есть участвовала в сторонних проектах в качестве программистов. Причем нам было интересно участвовать в долгосрочных и довольно крупных проектах, т.е. не менее 2-3 разработчиков и не менее 6 месяцев разработки. У нас было две цели:

• попробовать альтернативный тип бизнеса (заказную разработку помимо продуктовой разработки);
• самим посмотреть на использование PVS-Studio в долгосрочных проектах.

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

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

Три года назад мы уже проверяли Mozilla Firefox с помощью анализатора PVS-Studio. Тогда это было неудобно и затруднительно. Для Firefox отсутствует проектный файл для Visual Studio. Сборка осуществляется с помощью make-файлов. Поэтому просто взять и проверить проект нельзя. Требовалось интегрировать PVS-Studio в систему сборки, что оказалось трудной задачей. В результате, как мне помнится, была проанализирована только часть проекта. Но всё поменялось, когда появился PVS-Studio Standalone. Теперь можно отследить все запуски компиляторов и легко проверить проект.

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

Я проверил проект OpenMW с помощью PVS-Studio и написал эту крошечную статью. Нашлось слишком мало ошибок. Но меня просили написать про проверку этого проекта статью, и вот она.

Tesseract — свободная компьютерная программа для распознавания текстов, разрабатываемая компанией Google. В описании проекта говорится: «Tesseract is probably the most accurate open source OCR engine available». А давайте попробуем, сможет ли статический анализатор PVS-Studio распознать какие-то ошибки в этом проекте.