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

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

Эта статья является продолжением цикла публикаций об использовании PVS-Studio в облачных системах. На этот раз мы рассмотрим работу анализатора совместно с GitLab CI — продуктом от GitLab Inc. Интеграция статического анализатора в CI систему позволяет выявить баги сразу после этапа сборки проекта и является очень эффективным способом сократить затраты на обнаружение ошибок.

Постепенно и незаметно складывается ситуация, когда сложность серьёзных C++ проектов становится запредельной. К сожалению, теперь C++ программист не может полагаться только на свои силы.

Наше внимание привлёк репозиторий Electronic Arts на GitHub. Он очень маленький и из двадцати трёх проектов нас заинтересовали только несколько C++ библиотек: EASTL, EAStdC, EABase, EAThread, EATest, EAMain и EAAssert. Проекты оказались тоже очень маленькими (около 10 файлов), поэтому мы нашли ошибки только в «самом большом» из 20 файлов :D Но нашли, и интересные! Пока писалась заметка, мы с коллегами также бурно обсудили игры компании EA и её стратегию :D

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

Для корпорации Microsoft в последнее время стало 'доброй традицией' открывать исходные коды своих программных продуктов. Тут можно вспомнить про CoreFX, .Net Compiler Platform (Roslyn), Code Contracts, MSBuild и прочие проекты. Для нас, разработчиков статического анализатора PVS-Studio, это возможность проверить известные проекты, рассказать людям (и разработчикам в том числе) о найденных ошибках и потестировать анализатор. Сегодня речь пойдёт об ошибках, найденных в ещё одном проекте Microsoft — PowerShell.

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

Логическое выражение в программировании — конструкция языка программирования, результатом вычисления которой является «истина» или «ложь». Во многих книгах по программированию, предназначенных для изучения языка «с нуля», приводятся возможные операции над логическими выражениями, с которыми сталкивался каждый начинающий разработчик. В этой статье я не буду рассказывать, что оператор 'И' приоритетнее оператора 'ИЛИ'. Я расскажу о распространённых ошибках в простых условных выражениях, состоящих всего из трёх операторов, и покажу, как можно проверить свой код с помощью построения таблиц истинности. Описанные ошибки делают разработчики таких известных проектов как FreeBSD, Microsoft ChakraCore, Mozilla Thunderbird, LibreOffice и многих других.

Один из вечных вопросов, с которыми мы встречаемся, звучит так — «Вы проверяли PVS-Studio с помощью PVS-Studio? Где статья о результатах проверки?». Да, мы регулярно делаем это, поэтому мы никак не могли написать статью об ошибках, которые нашли сами в себе. Ошибки исправляются разработчиками ещё на этапе написания кода, и мы постоянно забываем в этот момент их выписать. Но читателям в этот раз повезло. Из-за недосмотра C# код плагина для Visual Studio не был добавлен в ежедневные ночные проверки, которые мы проводим. И, соответственно, в отличие от ядра анализатора, ошибки в нем не замечались на протяжении всего развития C# PVS-Studio. Как говорится, нет худа без добра, и благодаря этому вы и читаете данную статью.

Виртуальные машины используются для самых разных нужд. Сам я уже не один год использую VirtualBox для тестирования ПО и просто изучения различных дистрибутивов Linux, собственно, после длительного использования, периодически сталкиваясь с неопределённым поведением, я решил воспользоваться своим опытом в проверке open-source проектов и проанализировать исходный код Oracle VM Virtual Box.

В этой статье я продолжу описывать многочисленные подозрительные места, найденные в проекте.

Сегодня мы будем измерять производительность разных реализаций функции toupper, ведь именно этим и занимаются по вторникам.

Вообще-то мне нет никакого дела до функции toupper, просто я недавно писал другой пост и мне нужен был какой-то общий сюжетный стержень, а toupper кажется вполне интересным и безобидным кандидатом в бенчмарки. Я старался выбрать что-то максимально простое, что не увело бы меня в сторону, но так уж получилось, что в этом тесте я столкнулся со странной проблемой.

Не секрет, что Microsoft достаточно давно работает над выпуском восьмой версии C#. В недавно состоявшемся релизе Visual Studio 2019 новая версия языка (C# 8.0) уже доступна, но пока ещё только в качестве beta релиза. В планах этой новой версии есть несколько возможностей, реализация которых может показаться не совсем очевидной, или точнее, не совсем ожидаемой. Одним из таких нововведений стала возможность использования Nullable Reference типов. Заявленным смыслом данного нововведения является борьба с Null Reference Exception'ами (NRE).

Скорее всего, из названия статьи вы уже догадались, что в центре внимания ошибки в исходном коде. Но это вовсе не единственное, о чем пойдет речь в этой статье. Если кроме С++ и ошибок в чужом коде вас привлекают необычные игры и вам интересно узнать, что это такие за «рогалики» и с чем их едят, добро пожаловать под кат!

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

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

Введение

Perl — высокоуровневый интерпретируемый динамический язык программирования общего назначения (Perl is a family of two high-level, general-purpose, interpreted, dynamic programming languages). Разработка Perl 5 была начата в 1994 году. Спустя пару десятилетий, код на языке Си с многочисленными макросами вызывает нервозность у современных программистов.

Исходный код Perl 5 был взят из официального репозитория (ветка blead). Для проверки проекта использовался статический анализатор кода PVS-Studio. Анализ проводился на операционной системе Linux, но анализатор также доступен для Windows и macOS.

Просмотр результатов анализа был не простой задачей. Дело в том, что анализатор проверяет препроцессированные .i файлы, в которых уже раскрыты все директивы препроцессора, а выдаёт предупреждения на файлы с исходным кодом. Это правильное поведение анализатора, ничего менять не нужно, но много предупреждений выдаётся на макросы! А за макросами скрывается нечитабельный код.

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

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