Команда PVS-Studio хочет поделиться новостью и заранее подогреть интерес. Мы приступили к разработке анализатора для C#. С точки зрения пользователя это будет всё тот же старый добрый PVS-Studio, но мы научим его находить ошибки в программах на языке C#.

Одной из основных сложностей при использовании инструментов статического анализа является работа с ложными срабатываниями. Существует множество способов устранить ложные срабатывания, используя настройки анализатора или изменяя код. Я взял маленький проект Apple II emulator for Windows и покажу, как можно на практике работать с отчётом статического анализатора PVS-Studio. Покажу на примерах, как править ошибки и подавлять ложные срабатывания.

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

В прошлой заметке я рассказывал о проблемах с рекурсией в функции Фибоначчи при использовании 64-битных переменных в качестве ее аргументов и компиляции кода с помощью Microsoft Visual C++. Выяснилось, что компилятор включает хвостовую рекурсию, когда используются 32-битные переменные, но не делает этого при переходе к 64-битным. На всякий случай напомню, что хвостовая рекурсия – это оптимизация, производимая компилятором, при которой некоторые виды хвостовых вызовов преобразуются в безусловные переходы. Узнать больше о хвостовой рекурсии.

В этот раз я хочу поделиться с вами одной проблемой, с которой столкнулся, когда решил сравнить итерационные и рекурсивные функции в C++. Между рекурсией и итерацией есть несколько отличий: о них подробно рассказано в этой стать. В языках общего назначения вроде Java, C или Python рекурсия довольно затратна по сравнению с итерацией из-за необходимости каждый раз выделять новый стековый фрэйм. В C/C++ эти затраты можно легко устранить, указав оптимизирующему компилятору использовать хвостовую рекурсию, при которой определенные типы рекурсии (а точнее, определенные виды хвостовых вызовов) преобразуются в команды безусловного перехода. Для осуществления такого преобразования необходимо, чтобы самым последним действием функции перед возвратом значения был вызов еще одной функции (в данном случае себя самой). При таком сценарии безусловный переход к началу второй подпрограммы безопасен. Главный недостаток рекурсивных алгоритмов в императивных языках заключается в том, что в них не всегда возможно иметь хвостовые вызовы, т.е. выделение места для адреса функции (и связанных с ней переменных, например, структур) на стеке при каждом вызове. При слишком большой глубине рекурсии это может привести к переполнению стека из-за ограничения на его максимальный размер, который обычно на порядки меньше объема оперативной памяти.

Так получилось, что на днях Андрей Карпов принял участие в Positive Hack Days и выступил там с докладом. А Евгений Рыжков стал гостем SDCast'а, и в результате чего получился 40-минутный подкаст. В обоих случаях речь идёт о статическом анализе кода вообще, и анализаторе PVS-Studio в частности. Если Вам интересна эта тематика, то приглашаю под habracut, где можно узнать чуть больше деталей и увидеть ссылки на эти материалы.

Чуть больше года назад, мы решили провести эксперимент и выпустить альтернативу статического анализатора кода PVS-Studio для маленьких команд и индивидуальных разработчиков. Так появился очень недорогой анализатор под названием CppCat. Сейчас можно подвести итоги этого эксперимента и признать, что он оказался неудачным. За срок чуть более года он принёс приблизительно столько денег, сколько было потрачено на его разработку, продвижение и поддержку. Таким образом проект убыточен. Ведь потраченное время (самый ценный ресурс) мы могли бы использовать для совершенствования PVS-Studio. Мы вынуждены закрыть проект CppCat и сосредоточиться на PVS-Studio. Надеюсь, читателям будет интересен чужой опыт в реализации новой бизнес идеи. Негативный опыт — это тоже полезный опыт.

Мы временами экспериментируем с триальным режимом, чтобы знакомство с анализатором PVS-Studio проходило как можно эффективней. Сейчас мы вновь поменяли формат триальной версии. Эта заметка должна ответить на все вопросы, которое могут возникнуть у разработчиков, пожелавших познакомиться с нашим инструментом. Фактически эта статья является ответом на вопрос «можно ли попробовать демонстрационную версию и какие в ней ограничения?».

Вы открыли статью, на которую вы должны дать ссылку в Twitter. Или разместить в любимой программисткой группе. Это принесёт пользу и нам, и открытым проектам. Чтобы программисты всего мира узнали о PVS-Studio, мы проверяем открытые проекты и делаем их лучше. А заодно пишем интересные и полезные статьи. Чем больше люди будут узнавать про наши статьи, тем приятнее нам будет это делать и тем больше проектов мы будем проверять. Совместный profit.

Примечание от переводчика. Изначально эта статья была опубликована на сайте AltDevBlogADay. Но сайт, к сожалению, прекратил своё существование. Более года эта статья оставалась недоступна читателям. Мы обратились к Джону Кармаку, и он сказал, что не против, чтобы мы разместили эту статью на нашем сайте. Что мы с удовольствием и сделали. С оригиналом статьи можно познакомится, воспользовавшись Wayback Machine — Internet Archive: Static Code Analysis.

Поскольку все статьи на нашем сайте представлены на русском и английском языке, то мы выполнили перевод статьи Static Code Analysis на русский язык. А заодно решили опубликовать её на Хабре. Здесь уже публиковался пересказ этой статьи. Но уверен, многим будет интересно прочитать именно перевод.

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

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

Ненароком я породил большую дискуссию, касающуюся того, допустимо ли использовать в Си/Си++ выражение &P->m_foo, если P является нулевым указателем. Программисты разделились на два лагеря. Одни уверенно доказывали, что так писать нельзя, другие столь же уверенно утверждали, что можно. Приводились различные аргументы и ссылки. И я понял, что нужно внести окончательную ясность в этот вопрос. Для этого я обратился к экспертам Microsoft MVP и разработчикам Visual C++, общающимся через закрытый список рассылки. Они помогли подготовить эту статью, и я представляю её всем желающим. Для нетерпеливых: этот код не корректен.

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

Я считаю PVS-Studio очень качественным продуктом. Мы можем почти в любой день сделать и выложить дистрибутив. У нас используется очень большое количество автоматизированных тестов различного уровня и типов. Вот описание некоторых из них: "Как мы тестируем анализатор кода". Сейчас их стало больше. Например, теперь для статического анализа мы используем не только свой собственный анализатор, но и Clang. Если исправленная версия прошла все тесты, значит ее можно смело выдавать пользователям.

Оказывается, что вопрос, корректен или нет вот такой код &((T*)(0)->x), весьма непрост. Решил написать про это маленькую заметку.

Соавтор: Святослав Размыслов SvyatoslavMC.

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

CppCat – это простой статический анализатор кода для поиска ошибок в программах на языке Си/Си++. Мы начали выдавать бесплатные академические лицензии всем желающим (студентам, преподавателям и так далее). Для большей популяризации CppCat среди студентов я решил написать эту заметку об ошибках, которые можно найти в лабораторных работах, встречающихся на сайте Pastebin.com.

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

Я добрался до проекта Miranda NG и проверил его с помощью анализатора кода PVS-Studio. К сожалению, с точки зрения работы с памятью и указателями это самый неаккуратный проект из виданных мной. Хотя я внимательно не анализировал результаты, ошибок столь много, что я решил разбить собранный материал на 2 статьи. Первая статья будет посвящена указателям, а вторая всему остальному. Желаю приятного чтения, и не забудьте взять попкорн.

CppCat – это статический анализатор кода, интегрирующийся в среду Visual Studio 2010-2013. Анализатор предназначен для регулярного использования и позволяет выявить множество ошибок и опечаток в программах на языке Си и Си++. С целью его популяризации мы решили выдавать бесплатные лицензии всем студентам, которые к нам обратятся. Достаточно прислать фотографию студенческого билета или зачётной книжки.

Мне предложили проверить библиотеки, входящие в Visual Studio 2013. Ничего особенно примечательного я не нашёл. Только несколько мелких ошибок и недочётов. Интригующую статью из этого не сделаешь, но я всё равно опишу замеченные недостатки. Надеюсь, это сделает библиотеки чуть лучше, и подвигнет авторов провести более тщательную проверку. У меня нет файлов проектов для сборки библиотек. Поэтому я проверял файлы кое-как, и много могло быть пропущено.