На днях Google опубликовал исходники парсера robots.txt. Почему бы не прогнать уже проверенный всеми вдоль и поперек проект через PVS-Studio и, возможно, найти ошибку. Сказано — сделано. Жаль, что ничего значимого найти не удалось. Ну что ж, тогда пусть это будет просто повод похвалить разработчиков Google.

robots.txt – индексный файл, который содержит правила для поисковых роботов. Он действует для протоколов https, http и FTP. Google сделала доступным для всех свой парсер файла robots.txt. Подробнее об этой новости можно почитать здесь: Google открывает исходный код парсера robots.txt

На данный момент облачные CI-системы — очень востребованный сервис. В этой статье мы расскажем, как, с помощью уже существующих средств, доступных в PVS-Studio, можно интегрировать анализ исходного кода с облачной CI платформой, на примере сервиса Travis CI.

Многие наши статьи посвящаются чему угодно, но только не самому инструменту PVS-Studio. А ведь мы очень много делаем, чтобы разработчикам было удобно пользоваться нашим инструментом. Но как раз это часто оказывается за кадром. Решил исправить эту ситуацию и рассказать о плагине PVS-Studio для Visual Studio. Если вы используете Visual Studio, то эта статья для вас.

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

Введение

Multi-character-литерал является implementation-defined, поэтому различные компиляторы могут кодировать эти литералы по-разному. К примеру, GCC и Clang задают значение, основываясь на порядке символов в литерале, тогда как MSVC перемещает их в зависимости от типа символа (обычный или escape).

Время от времени программисты, которые начинают знакомиться с анализатором кода PVS-Studio, спрашивают: «Есть ли список предупреждений, которые точно указывают на ошибки?» Такого списка нет по той причине, что неинтересные (ложные) предупреждения в одном проекте, в другом оказываются очень важными и полезными. Однако начать знакомство с анализатором с самых интересных предупреждений вполне можно. Давайте рассмотрим эту тему подробнее.

С момента появления продукта PVS-Studio прошло более 8 лет, и всё это время мы реализовывали в нём новые диагностические правила. И прекращать не собираемся. Если вас заботят вопросы, не растеряли ли мы за эти годы бодрость, и не останавливается ли PVS-Studio в развитии, то приведённый в статье график снимет эти вопросы. Анализатор активно развивается, причём скорость развития с годами только увеличивается.

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

Поддержка Visual Studio 2019 в PVS-Studio затронула сразу несколько различных компонентов: сам плагин для IDE, command line приложение для анализа, ядра C++ и C# анализаторов, а также несколько утилит. О том, с какими проблемами мы столкнулись в ходе поддержки новой версии IDE и как их решали, я кратко расскажу в данной статье.

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

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

Иногда люди задают вопрос, который, на первый взгляд, про одно, а на самом деле про другое. Как говорится, грамотно поставленный вопрос содержит половину ответа.

На днях я вернулся с конференции JPoint, на которой впервые был представлен наш новый анализатор PVS-Studio для Java. Интерес к статическому анализу сильно растет в последние несколько лет, поэтому аудитория восприняла PVS-Studio на ура. Кроме положительных откликов, естественно, пришлось и поработать с возражениями. Самое частое возражение на предложение попробовать PVS-Studio звучит так: «Да ладно, зачем нам пробовать PVS-Studio? Мы используем IntelliJ IDEA, ReSharper, SonarLint и SonarQube. Вот мы запустили недавно PVS-Studio, и он нашел ошибки, которые и так подсвечивает IntelliJ IDEA!»

Я просто не могу не написать небольшую заметку-ответ на этот комментарий. Точнее, у меня даже два ответа на это возражение. И да, я специально указал здесь ReSharper, так как к нашему анализатору для C# такие вопросы тоже имеют место. Что ж, с радостью отвечу.

Для Java программистов существуют полезные инструменты, помогающие писать качественный код, например, мощная среда разработки IntelliJ IDEA, бесплатные анализаторы SpotBugs, PMD и другие. Всё это уже используется в разработке проекта CUBA Platform, и в этом обзоре найденных дефектов кода я расскажу, как ещё можно улучшить качество проекта, используя статический анализатор кода PVS-Studio.

Это второй обзор из цикла статей о проверке открытых программ для работы с протоколом RDP. В ней мы рассмотрим клиент rdesktop и сервер xrdp.

Wireshark Foundation выпустила финальную stable-версию популярного сетевого анализатора трафика — Wireshark 3.0.0. В новом релизе устранено несколько багов, реализована возможность анализа новых протоколов и заменен драйвер WinPcap на Npcap. Здесь заканчивается цитирование анонса и начинается наша заметка о багах в проекте. Перед релизом их было исправлено явно недостаточно. Давайте насобираем исправлений, чтобы был повод делать новый релиз :).

Введение

Wireshark — это достаточно известный инструмент для захвата и анализа сетевого трафика. Программа работает с подавляющим большинством известных протоколов, имеет понятный и логичный графический интерфейс, мощнейшую систему фильтров. Wireshark — кроссплатформенный, работает в таких ОС, как: Windows, Linux, macOS, Solaris, FreeBSD, NetBSD и многих других.

Для поиска ошибок использовался статический анализатор PVS-Studio. Для анализа исходного кода необходимо предварительно скомпилировать проект в какой-нибудь операционной системе. Выбор был большой не только из-за кроссплатформенности проекта, но и из-за кроссплатформенности анализатора. Для анализа проекта я выбрал macOS. Также запуск анализатора возможен в Windows и Linux.

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

Время от времени мы возвращаемся к проектам, которые уже проверяли ранее с помощью PVS-Studio и писали про это статьи. Делать это интересно по двум причинам. Во-первых, чтобы понять, насколько лучше стал наш анализатор. Во-вторых, чтобы отследить, обратили ли авторы проекта внимание на нашу статью, а также на отчет об ошибках, который мы им обычно предоставляем. Конечно, ошибки могут быть исправлены и без нашего участия. Но всегда приятно, когда именно наши усилия помогают сделать какой-то проект лучше. Не стал исключением и Roslyn. Предыдущая статья о проверке этого проекта датируется 23 декабря 2015 года. Это довольно давно, учитывая путь, который за это время проделал в своём развитии наш анализатор. Дополнительный интерес лично для нас Roslyn представляет ещё и тем, что на нём базируется ядро C# анализатора PVS-Studio. Таким образом, мы очень заинтересованы в качестве кода этого проекта. Устроим ему повторную проверку и выясним, что же нового и интересного (но будем надеяться, что ничего существенного) там сможет найти PVS-Studio.

Далеко не первый год команда PVS-Studio ведет блог о проверках open-source проектов одноименным статическим анализатором кода. На сегодняшний момент проверено более 300 проектов, а в базу найденных ошибок выписано более 12000 случаев. Изначально анализатор был реализован для проверки C и C++ кода, далее появилась поддержка языка C#. Поэтому среди проверенных проектов большая часть (> 80%) приходится именно на C и C++. Совсем недавно к поддерживаемым языкам прибавился Java, а это значит, что перед PVS-Studio открываются двери в новый мир, и пора дополнять базу ошибками из Java проектов.

Java мир огромен и многообразен, поэтому глаза разбегаются при выборе проекта для испытания нового анализатора. В конечном итоге, выбор пал на движок полнотекстового поиска и аналитики Elasticsearch. Это достаточно успешный проект, а в успешных проектах находить ошибки вдвойне, а то и втройне приятнее. Так что, какие же дефекты обнаружил PVS-Studio для Java? О результате проверки и пойдет речь в статье.

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

Язык C++ открывает обширные возможности для того, чтобы обходиться без макросов. Так давайте попробуем использовать макросы как можно реже!

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

BEGIN_MESSAGE_MAP(efcDialog, EFCDIALOG_PARENT )
  //{{AFX_MSG_MAP(efcDialog)
  ON_WM_CREATE()
  ON_WM_DESTROY()
  //}}AFX_MSG_MAP
END_MESSAGE_MAP()

Существуют такие макросы, да и ладно. Они действительно были созданы для упрощения программирования.

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

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

Исследование кода калькуляторов продолжается! В этом обзоре будет рассмотрен проект SpeedCrunch — второй по популярности среди бесплатных калькуляторов.

Введение

SpeedCrunch — это высокоточный научный калькулятор с быстрым пользовательским интерфейсом, управляемый с клавиатуры. Это бесплатное программное обеспечение с открытым исходным кодом, доступное на Windows, Linux и macOS.

Исходный код размещён на BitBucket. Мне не очень понравилась документация по сборке, которую, на мой взгляд, стоило бы написать подробнее. В требованиях указан «Qt 5.2 or later», хотя понадобилось несколько конкретных пакетов, о которых было непросто узнать из лога CMake. Кстати, сейчас хорошей практикой считается прикладывать Dockerfile к проекту для быстрой настройки нужного окружения разработчика.