The 7.0 release marked a new milestone in the history of the PVS-Studio analyzer — the analysis is now available not only for the code, written in C, C++, C#, but also in Java. In addition to this global improvement, some existing mechanisms for the analysis are refined and improved, diagnostic rules are added. There was another significant change that you could hardly missed. We changed the icon.
Note. In the article, you will not find cunning tricks or tips on designing icons. The purpose of the article is a bit different this time — it is to tell a story, and, if possible, make it interesting.
Связующее звено сегодняшней статьи отличается от обычного. Это не один проект, для которого был проведён анализ исходного кода, а ряд срабатываний одного и того же диагностического правила в нескольких разных проектах. В чём здесь интерес? В том, что некоторые из рассмотренных фрагментов кода содержат ошибки, воспроизводимые при работе с приложением, а другие – и вовсе уязвимости (CVE). Кроме того, в конце статьи немного порассуждаем на тему дефектов безопасности.
Не только Microsoft в последнее время выкладывает код собственных проектов в открытый доступ — другие компании тоже следуют этой тенденции. Для нас же — разработчиков PVS-Studio — это отличный способ ещё раз протестировать анализатор, посмотреть, что интересного он сможет найти, и сообщить об этом авторам проекта. Сегодня заглядываем внутрь проекта компании Fast Reports.
Публикация корпорацией Microsoft исходников своих проектов является вполне хорошим поводом для их проверки. Этот раз исключением не стал, и сегодня мы посмотрим на подозрительные места, найденные в коде Infer.NET. Долой аннотацию – ближе к делу!
Если вы занимаетесь разработкой ПО в сфере видеоигровой индустрии и задаётесь вопросом о том, что ещё можно сделать, чтобы повысить качество продукта \ упростить процесс разработки, и при этом не используете статический анализ — самое время начать. Сомневаетесь? Что ж, я попробую вас в этом убедить. Если же вам просто интересно посмотреть на ошибки, которые допускают разработчики из сферы видеоигровой индустрии, то, опять же, вы попали по адресу — специально для вас отобраны наиболее интересные.
За окном уже почти как 3 месяца стоит 2018 год, а это значит, что пришло время (пусть и немного запоздало) составить топ 10 ошибок, найденных анализатором PVS-Studio в C++ проектах за прошедший год. Итак, начнём!
Сегодняшняя статья несколько необычна. Как минимум по той причине, что вместо анализа одного проекта, будем искать ошибки сразу в трёх, а также посмотрим, где найдутся наиболее интересные баги. А самое интересное — мы выясним, кто молодец и пишет самый качественный код. Итак, на повестке дня — разбор ошибок в коде проектов Firebird, MySQL и PostgreSQL.
Эта небольшая заметка является промежуточным итогом на тему поиска уже известных уязвимостей в open source C# проектах. Я хотел посмотреть на примеры кода, который бы являлся уязвим и был причиной появления очередной CVE, но оказалось, что не всё так просто…
Уязвимость в терминах компьютерной безопасности — недостаток в системе, позволяющий намеренно нарушить её целостность или вызвать неправильную работу. Как показывает практика, даже, казалось бы, незначительный баг может являться серьёзной уязвимостью. Уязвимостей можно избежать, используя различные методики валидации и верификации программного обеспечения, в том числе — статический анализ. О том, как с задачей поиска уязвимостей справляется PVS-Studio, и пойдёт речь.
Для корпорации Microsoft в последнее время стало 'доброй традицией' открывать исходные коды своих программных продуктов. Тут можно вспомнить про CoreFX, .Net Compiler Platform (Roslyn), Code Contracts, MSBuild и прочие проекты. Для нас, разработчиков статического анализатора PVS-Studio, это возможность проверить известные проекты, рассказать людям (и разработчикам в том числе) о найденных ошибках и потестировать анализатор. Сегодня речь пойдёт об ошибках, найденных в ещё одном проекте Microsoft — PowerShell.
Крупные проекты проверять интересно. Как правило, в них удаётся найти различные интересные ошибки и рассказать о них людям. Также это хороший способ тестирования нашего анализатора и улучшения различных его аспектов. Я давно хотел проверить 'Mono', и наконец-то такая возможность появилась. И, стоит сказать, проверка себя оправдала, так как удалось найти много занимательного. О том, что же нашлось, какие нюансы возникли при проверке, и будет эта статья.
Статьи о проверке проектов с открытым исходным кодом — вещь полезная. Кто-то, в том числе и разработчики, узнает об ошибках, содержащихся в проекте, кто-то узнает о методологии статического анализа и начнет применять её для повышения качества своего кода. Для нас же это прекрасный способ популяризации анализатора PVS-Studio, а заодно возможность его дополнительного тестирования. На этот раз я проверил платформу Accord.Net и нашёл в коде много интересных фрагментов.
Несмотря на то, что использовать механизм сериализации при программировании на C# достаточно просто и удобно, есть моменты, которые стоит учитывать. О том, на какие грабли можно наступить, работая с сериализацией, о примерах кода, в котором эти грабли припрятаны, а также о том, как PVS-Studio поможет вам избежать шишек на лбу, и будет эта статья.
Не так давно, как вы наверняка знаете, корпорация Microsoft купила компанию Xamarin. Даже несмотря на то, что в последнее время Microsoft начала постепенно открывать исходные коды своих продуктов, открытие кода Xamarin.Forms стало большим сюрпризом. Я не смог пройти мимо такого события, и решил проверить исходный код этого проекта с помощью статического анализатора кода.
Roslyn является платформой, предоставляющей разработчику различные мощные средства для разбора и анализа кода. Но наличия таких средств недостаточно, нужно понимать, что и для чего необходимо использовать. Данная статья несёт цель ответить на подобные вопросы. Помимо этого, будет рассказано об особенностях разработки статических анализаторов, использующих Roslyn API.
Повторная проверка проектов нередко бывает весьма интересной. Она позволяет узнать, какие новые ошибки были допущены в ходе разработке приложения, а какие ошибки уже были исправлены. Раньше мой коллега уже писал о проверке PHP. С выходом новой версии (PHP7), я решил ещё раз проверить исходный код интерпретатора и нашёл кое-что интересное.
Движков с открытым исходным кодом, написанных на C++, куда больше, чем аналогичных движков, написанных на C#. Но есть исключения. Xenko – один из движков, написанных на C# и имеющих открытый исходный код. О том, что же интересного удалось найти в коде этого движка, будет рассказано в этой статье.
Как вы уже поняли из заголовка, речь в статье будет идти о подозрительных местах, найденных в исходном коде 'Space Engineers'. Но формат статьи несколько отличается от остальных. Помимо информации о проекте, обзора некоторых найденных подозрительных мест и ошибок, а также способов их исправления, я включил в текст небольшой раздел о правильном сценарии использования статического анализатора. Настоятельно рекомендую ознакомиться с ним, так как многие разработчики не знают или просто не задумываются о том, как правильно использовать инструменты этого класса. В результате инструменты статического анализа используются на порядок менее эффективно, чем могли бы.
Как некоторые из вас помнят — недавно мы выпустили версию анализатора, поддерживающую проверку C#-кода. С появлением возможности анализа проверки проектов, написанных на C#, открывается новый простор для творчества. Об анализе одного из таких проектов, разработанного компанией Sony Computer Entertainment (SCEI), и пойдёт речь в данной статье.
