Авторы анализатора PVS-Studio предлагают вам проверить свою внимательность.

Анализаторы кода работают без устали и умеют находить множество ошибок, которые сложно заметить. Мы отобрали некоторые фрагменты кода, в которых мы выявили ошибки с помощью PVS-Studio. Все фрагменты взяты из известных Open-Source проектов.

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

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

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

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

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

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

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

Ничего эпического в этой статье не будет. Мы проверили с помощью 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 распознать какие-то ошибки в этом проекте.

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

Поддержка проектов, написанных на C++/CLI не является приоритетным направлением в PVS-Studio. Таких проектов достаточно мало, но тем не менее время от времени мы сталкиваемся с ними. Компания Microsoft на данный момент не планирует прекратить поддержку языка C++/CLI, поэтому мы решили всё-таки поддержать эту разновидность языка.

Мы постоянно проверяем открытые проекты на языке Си/Си++. Но почти всегда, это проекты, разрабатываемые в Visual Studio. А вот Embarcadero C++ Builder мы как-то обделили вниманием. Нужно исправляться и сегодня мы проверили проект WinSCP.

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

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