В ноябре прошлого года в нашем блоге была опубликована статья о разработке и использовании плагина PVS-Studio для SonarQube. Мы получили много откликов от клиентов и просто заинтересованных пользователей с просьбами провести тестирование плагина на реальном проекте. Так как интерес к этому вопросу не ослабевает, было решено провести тестирование на C# проекте PascalABC.NET. Также не будем забывать, что SonarQube содержит собственный статический анализатор C# кода — SonarC#. Для полноты картины проведем исследование и SonarC#. Целью данной работы является не сравнение анализаторов, а показ основных особенностей их взаимодействия с сервисом SonarQube. Прямое сравнение анализаторов было бы не вполне корректным по той причине, что PVS-Studio является специализированным инструментом поиска ошибок и потенциальных уязвимостей, в то время как SonarQube — это сервис оценки качества кода по большому числу параметров: дублирование кода, соблюдение стандартов кодирования, покрытие кода модульными тестами, возможные ошибки в коде, плотность комментариев в коде, технический долг и т.д.

Мы решили в меру своих сил регулярно искать и устранять потенциальные уязвимости и баги в различных проектах. Можно назвать это помощью open-source проектам. Можно — разновидностью рекламы или тестированием анализатора. Еще вариант — очередной способ привлечения внимания к вопросам качества и надёжности кода. На самом деле, не важно название, просто нам нравится это делать. Назовём это необычным хобби. Давайте посмотрим, что интересного было обнаружено в коде различных проектов на этой неделе. Мы нашли время сделать исправления и предлагаем вам ознакомиться с ними.

Недавно мы опубликовали 2 статьи про ТОП 10 ошибок в открытых проектах C++ и C# за предыдущий 2016 год. Статьи понравились читателям и это натолкнуло на мысль: почему бы не сделать такой ТОП для каждого месяца? Ведь на нашем сайте огромная база ошибок, которая хорошо структурирована и из которой можно выбрать самые интересные баги, найденные в определенный промежуток времени. В этой заметке будет рассказано о новой рубрике «Баг месяца» и о том, из чего мы исходили, когда готовили список ошибок для нее.

В своей предыдущей статье я писал, что мне не нравится подход, при котором статические анализаторы кода оцениваются с помощью синтетических тестов. В статье приводился пример, воспринимаемый анализатором как особый случай, на который сознательно не выдаётся предупреждение. Если честно, я не ожидал такого всплеска комментариев на тему того, что анализатор может очень редко, но не выдать предупреждение на ошибку из-за реализованных в нём механизмов отсечения ложных срабатываний. Борьба с ложными срабатываниями настолько большая составляющая любого статического анализатора, что как-то даже не понятно, что тут собственно обсуждать. Это надо делать и всё. Такие механизмы существуют не только в нашем анализаторе, но и в других анализаторах/компиляторах. Тем не менее, раз этот момент вызвал столь бурное обсуждение, я думаю, стоит уделить ему внимание, поэтому и написал эту поясняющую статью.

Мы решили в меру своих сил регулярно искать и устранять потенциальные уязвимости и баги в различных проектах. Можно назвать это помощью open-source проектам. Можно — разновидностью рекламы или тестированием анализатора. Еще вариант — очередной способ привлечения внимания к вопросам качества и надёжности кода. На самом деле, не важно название, просто нам нравится это делать. Назовём это необычным хобби. Давайте посмотрим, что интересного было обнаружено в коде различных проектов на этой неделе. Мы нашли время сделать исправления и предлагаем вам ознакомиться с ними.

Анализатор PVS-Studio всегда умел искать множество различных дефектов безопасности (потенциальных уязвимостей) в коде программ. Однако, исторически сложилось, что мы позиционировали PVS-Studio как инструмент для поиска ошибок. Сейчас наблюдается мода на поиск в коде именно уязвимостей, а не ошибок, хотя на самом деле это одно и тоже. Что же, значит пришло время провести ребрендинг нашего статического анализатора PVS-Studio. Начнём мы с Common Weakness Enumeration (CWE). В этой статье приводится таблица, сопоставляющая диагностические предупреждения PVS-Studio с классификатором. Таблица будет постепенно пополняться и изменяться, но уже сейчас с её помощью мы сможем писать статьи, посвященные обнаруженным дефектам безопасности в том или ином проекте. Думаем, это привлечёт к нашему инструменту больше внимания специалистов, занимающихся безопасностью программного обеспечения.

Микроклоны — это дублированные фрагменты кода очень малого размера — всего лишь несколько инструкций или строк. В этой статье мы рассмотрим «эффект последней строки» — явление, при котором последняя строка или инструкция в микроклоне с гораздо большей вероятностью содержит ошибку, чем предыдущие строки или инструкции. С этой целью мы изучили 219 открытых проектов и 263 предупреждения о дефектных микроклонах, а также опросили шестерых авторов реальных приложений, допускавших такие ошибки в своем коде. В нашей междисциплинарной работе также изучаются психологические механизмы, обуславливающие сравнительно тривиальные ошибки этого типа. Опираясь на результаты опросов и дальнейшего технического анализа, мы предполагаем, что в существовании эффекта последней строки ключевую роль играют так называемые «ошибки последовательности действий»: при копировании кода внимание разработчиков переключается на другие задачи из-за отвлекающих факторов и монотонной природы самой этой процедуры. Более того, все микроклоны, чье происхождение мы смогли установить, были обнаружены в непривычно больших коммитах. Знание о данном эффекте имеет два полезных следствия для программистов:

1) им будет легче распознавать ситуации, в которых особенно велика вероятность допустить ошибку в микроклонах;

2) они смогут использовать автоматический детектор микроклонов / PVS-Studio, что упростит обнаружение ошибок этого типа.

Мы решили в меру своих сил регулярно искать и устранять уязвимости и баги в различных проектах. Можно назвать это помощью open-source проектам. Можно — разновидностью рекламы или тестированием анализатора. Еще вариант — очередной способ привлечения внимания к вопросам качества и надёжности кода. На самом деле, не важно название, просто нам нравится это делать. Назовём это необычным хобби. Давайте посмотрим, что интересного было обнаружено в коде различных проектов на этой неделе. Мы нашли время сделать исправления и предлагаем вам ознакомиться с ними.

Пока во всём мире обсуждают 89-ю церемонию вручения наград премии «Оскар» и составляют различные рейтинги актёров и их костюмов, мы решили подготовить обзорную статью в IT-сфере. Речь пойдёт о самых интересных ошибках, допущенных в проектах с открытым исходным кодом в 2016 году. Этот год был примечателен тем, что наш анализатор PVS-Studio стал доступен и в операционных системах, основанных на Linux. Представленные ошибки наверняка уже исправлены, и каждый читатель может убедиться в серьёзности ошибок, которые допускают разработчики.

Популярность бесплатного варианта лицензирования PVS-Studio постепенно растёт, и всё больше бесплатных пользователей обращаются к нам в поддержку с различными вопросами. Многие вопросы повторяют друг друга и, чтобы сократить объем переписки, мы с настоящего момента будем оказывать поддержку бесплатным пользователям только через сайт StackOverflow. Так нам будет проще работать с вопросами, и мы сможем давать ссылки на более ранние ответы. Кроме того, множество вопросов просто отпадёт, так как ответ можно будет сразу найти с помощью поиска на StackOverflow, и не потребуется ожидать ответа по почте. Данное решение облегчит жизнь как нам, так и пользователям PVS-Studio.

Media Portal 2 — это открытое программное обеспечение класса медиа центр, которое позволяет смотреть видео, фотографии, слушать музыку и многое другое. Для нас, разработчиков статического анализатора PVS-Studio, это еще одна возможность проверить интересный проект, рассказать людям (и разработчикам в том числе) о найденных ошибках и, в свою очередь, еще раз показать возможности нашего анализатора.

Для оценки качества работы нашего анализатора, а также с целью популяризации методологии статического анализа, мы регулярно проверяем на наличие ошибок проекты с открытым исходным кодом и пишем про это статьи. Не стал исключением и прошедший 2016 год, который примечателен ещё и тем, что это было время своеобразного «взросления» C# анализатора. PVS-Studio получил значительное количество новых C# диагностик, улучшенный механизм работы с виртуальными значениями (symbolic execution) и многое другое. По результатам проделанной нашей командой работы, я составил своеобразный хит-парад наиболее интересных ошибок, обнаруженных в проектах С# в 2016 году.

История — это опыт, который позволяет современному поколению не наступить вновь на грабли. Но в программировании, как и в других активно развивающихся областях, такой идеальный сценарий не всегда возможен. Почему? Потому что появляются новые языки программирования, многие процессы становятся сложнее, а машины умнее. В этой статье я приведу две реальные истории. Что их объединяет? Во-первых, время — все они произошли в СССР; во-вторых, люди — каждая история могла пойти по другому сценарию, если бы главные герои не проявили свои лучшие/худшие человеческие качества; в-третьих, конечно же, программирование, иначе статья была бы просто неуместна в нашем блоге.

Одним из популярных файловых менеджеров в среде Microsoft Windows является Far Manager, принявший эстафету у Norton Commander, созданной еще для DOS. Far Manager позволяет облегчить работу с файловой системой (создание, редактирование, просмотр, копирование, перемещение, поиск, удаление файлов), а также расширяет стандартный функционал (работа с сетью, архивами, резервными копиями и т.д.). Недавно была произведена работа по портированию Far Manager на Linux, и на текущий момент была выпущена альфа-версия. Команда PVS-Studio не могла обойти стороной данное событие и решила проверить качество адаптированного кода.

В этой статье мне хотелось бы поделиться результатами проверки статическим анализатором 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. И вообще, это не «мнение», я знаю это!