В этой статье мне хотелось бы поделиться результатами проверки статическим анализатором PVS-Studio открытой реализации сервера игры World of Warcraft – CMaNGOS.

Введение

C(ontinued)MaNGOS является активно развивающимся ответвлением старого проекта MaNGOS (Massive Network Game Object Server), призванного создать свободный альтернативный сервер для игры World of Warcraft. Большая часть разработчиков MaNGOS продолжает работу в проекте CMaNGOS.

Как пишут сами разработчики, их цель – создать открытый «well written server in C++» для одной из лучших MMORPG. Постараюсь немного помочь им в этом, и проверю CMaNGOS при помощи статического анализатора PVS-Studio.

Примечание: Для проверки использовался сервер CMaNGOS-Classic, доступный в репозитории проекта на github.

Введение

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

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

Итак, всё началось со статьи: Как использовать PVS-Studio бесплатно.

Проверка проектов с помощью статического анализатора и написание обзорных статей с найденными в них ошибками – задача не из лёгких. Почти всегда это работа не одного человека, а коллектива. Большую роль в этом процессе играет выбор проекта. От него напрямую зависит интерес читателей к той или иной статье. В этой заметке я хочу рассказать, как можно предложить интересный проект для анализа через GitHub.

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

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

Не так давно Bill Torpey написал в своем блоге заметку "Even Mo' Static", где рассказал, как, на его взгляд, показали себя инструменты Cppcheck и PVS-Studio при анализе проекта itc-benchmarks. Проект itc-benchmarks — это static analysis benchmarks from Toyota ITC.

Мне не понравилось, что после прочтения статьи создается впечатление, что анализаторы Cppcheck и PVS-Studio приблизительно равны в своих возможностях. Из статьи следует, что один анализатор показывает себя лучше в одном, второй в другом, но в целом их диагностические возможности похожи.

Я думаю, что это не так. Мое мнение — наш анализатор PVS-Studio в несколько раз мощнее, чем Cppcheck. И вообще, это не «мнение», я знаю это!

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

Еще в далеком 2005 с выходом стандарта C# 2.0 появилась возможность передачи переменной в тело анонимного делегата посредством ее захвата (или замыкания, кому как угодно) из текущего контекста. В 2008 вышел в свет новый стандарт C# 3.0, принеся нам лямбды, пользовательские анонимные классы, LINQ запросы и многое другое. Сейчас на дворе январь 2017 и большинство C# разработчиков с нетерпением ждут релиз стандарта C# 7.0, который должен привнести много новых полезных «фич». А вот фиксить старые «фичи», никто особо не торопится. Поэтому способов случайно выстрелить себе в ногу по-прежнему хватает. Сегодня мы поговорим об одном из их, и связан он с не совсем очевидным механизмом захвата переменных в тело анонимных функций в языке C#.

PVS-Studio — статический анализатор исходного кода для поиска ошибок и уязвимостей в программах на языке C, C++ и C#. В этой статье я хочу дать обзор технологий, которые мы используем в анализаторе PVS-Studio для выявления ошибок в коде программ. Помимо общей теоретической информации я буду на практических примерах показывать, как та или иная технология позволяет выявлять ошибки.

Введение

Поводом для написания статьи стало моё выступление с докладом на открытой конференции ИСП РАН 2016 (ISPRAS OPEN 2016), проходившей в первых числах декабря в Главном здании Российской академии наук. Тема доклада: «Принципы работы статического анализатора кода PVS-Studio» (презентация в формате pptx).

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

Десять лет назад мы создали простенькую утилиту под названием Viva64, предназначенную для выявления некоторых проблем в 64-битном коде. Так было заложено начало статического анализатора кода PVS-Studio. Хотя с того момента прошло 10 лет, что-то более-менее у нас, как у компании, стало получаться только несколько лет назад. Эта статья — не история успеха, так как мы считаем, что всё интересное только начинается. Однако, 10 лет — это повод подвести промежуточные итоги и рассказать нашим читателям как все начиналось, какие нас ждали ошибки, и что на данный момент у нас получилось. Местами я, возможно, буду не совсем хронологически точен при описании событий. Моя память не идеальна, а 10 лет — это длительный промежуток времени. Желаю всем приятного чтения.

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

Оригинальная статья была написана Bartlomiej Filipek и опубликована в его блоге.

Вспомогательные средства

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

Сайту viva64.com — основной площадке разработчиков анализатора кода PVS-Studio исполнилось 10 лет! Домен был зарегистрирован 09.11.2006 года, а последнее серьезное обновление дизайна было выполнено в декабре 2010 года. Пришло время что-то поменять.

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

Перед вами рассказ о Злобном Баге. О том, как он неоднократно пытался испортить новогодние праздники. Часто ему удавалось воплотить свои коварные замыслы, но, к счастью, в каждой Сказке «злу» противостоит настоящее «добро».

Время неумолимо. Казалось бы, только недавно мы анонсировали выход статического анализатора для C# кода, проверили первые проекты и начали писать про это статьи. И вот уже прошел целый год с этого момента. Год кропотливой и сложной работы по улучшению характеристик анализатора, добавлению новых диагностических правил, сбору статистики ложных срабатываний и устранению их причин, взаимодействию с пользователями и решению массы других вопросов. Год множества маленьких и больших побед на том трудном, но невероятно интересном пути, который мы для себя выбрали. Пришло время повторной проверки проекта, первым попавшего к нам для исследования с помощью нового C# анализатора год назад — Umbraco.

В 1971 году СССР доставили на Марс первые в мире планетоходы «на лыжах», которые должны были щупом (динамический пенетрометр и гамма-лучевой плотномер) ткнуть поверхность, и сказать — Марс твердый или жидкий пыльный. Первый аппарат разбился 27 ноября, второй совершил мягкую посадку 2 декабря, но марсоходик не смог выбраться из «скорлупы» посадочного модуля, поэтому попытку не засчитали.

Прошло 25 лет.
4 июля 1997 года на Марс прилетел американский аппарат и привез «пришельца» с первым багом.


Кадр из к/ф «Марсианин». Главный герой держит в руках марсоход Sojourner

Проект был под угрозой, но мощные инструменты отладки операционной системы и отличная работа программистов на Земле (парни, что надо) позволили в кратчайшие сроки все быстренько исправить.

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

Почему я про это рассказываю? Мы тоже хотим участвовать в этой конференции, и я уже отправил на рассмотрение свою тему доклада. Присоединяйтесь!

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

Введение

Клиентами анализатора PVS-Studio являются отделы разработчиков различных компаний. Мы бы хотели, чтобы нашими клиентами были и индивидуальные разработчики. К сожалению, у нас ничего не получилось с экспериментальным продуктом CppCat. Мы не знаем, как построить успешный бизнес в сфере статического анализа кода, продавая персональные лицензии. Поэтому сейчас продукт PVS-Studio позиционируется исключительно как B2B решение.

Думаю, что наш провал с CppCat был предопределён. Мир диктует свои законы, и, например, тот же Coverity ориентирован на корпоративные лицензии. Однако, это не значит, что нужно исключать другие варианты взаимодействия с миром.

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

Стоит пояснить нашу позицию. Впрочем, если вам не терпится, вы можете сразу перейти к разделу «Бесплатная лицензия PVS-Studio». Если же читателю интересно узнать подробности, то предлагаю продолжить чтение.

Orchard — это бесплатная система управления контентом с открытым исходным кодом, являющаяся частью галереи ASP.NET-проектов с открытым исходным кодом некоммерческого фонда Outercurve Foundation.


Для нас, разработчиков статического анализатора PVS-Studio, это еще одна возможность проверить интересный проект, рассказать людям (и разработчикам в том числе) о найденных ошибках и, в свою очередь, еще раз протестировать наш анализатор. Сегодня речь пойдёт об ошибках, найденных в проекте Orchard CMS.

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

Будучи общепризнанными лидерами и вдохновителями индустрии статического анализа, мы (Gimpel Software) польщены тем, что другие компании ориентируются на наш продукт как на эталон качества при разработке своих инструментов. Обычно мы не считаем нужным как-либо реагировать на публикации о результатах сравнений нашего анализатора с другими продуктами, однако «экспертный отчет», выпущенный компанией Grammatech и посвященный сравнению инструментов CodeSonar и PC-lint, оказался крайне неприятным исключением. Вместо того чтобы сосредоточиться на достоинствах своего продукта, авторы этого документа прибегли к ложным заявлениям в адрес PC-lint и искажению фактов относительно его технических возможностей, что, вероятно, явилось следствием давления со стороны рынка, и мы считаем своим долгом ответить на эту ложь, рассказав о реальном положении дел.

Недавно вышла в свет Linux-версия анализатора PVS-Studio. С ее помощью был проверен ряд проектов с открытым исходным кодом. Среди них Chromium, GCC, LLVM (Clang) и другие. И сегодня к этому списку присоединятся проекты, которые были разработаны Walt Disney Animation Studios для сообщества специалистов по созданию виртуальной реальности. Давайте приступим к рассмотрению найденных предупреждений анализатора.