Проверка проекта OpenJDK с помощью PVS-Studio

[istui]

Вопрос не совсем по теме: умеет ли PVS-studio находить ошибки вида

auto average = total / x.size();

?

Имеется в виду: (1) возможное деление на ноль и (2) отсутствие проверок в коде на (1)?
Пробная версия, к сожалению, эти места не обнаружила. Если такого функционала нет, я думаю, есть смысл его добавить — подобный код встречается не так уж и редко…

[DieselMachine]

Если выдавать предупреждение на каждое деление, то будет много ложных срабатываний.
Мы сделали так: если выражение в знаменателе было как-то ограничено, например в условии блока if, или это счётчик цикла, который принимает ограниченное количество значений и ноль в него тоже входит, тогда выдаём предупреждение.

[istui]

В итоге получается, что случай, приведенный мной выше, анализатор пропускает, а при выполнении программы в редких кейсах размер вектора становится равным нулю, и все падает…

Было бы неплохо все же иметь хоть какую-то опцию, вроде «расширенная проверка деления на ноль», по умолчанию отключенную для удобства.

[Andrey2008]

Нет, это плохая идея. Это тоже самое, что просто показать в программе все деления (ну кроме деления на константу). При реализации хотя-бы пяти таких диагностик анализатор превращается в тыкву.

[tagir_valeev]

{ return sizeof(Method)/wordSize + (is_native()? 2: 0); }

Вообще разработчики OpenJDK тоже пользуются статическим анализом. Это довольно свежий код и эту багу уже исправили 7 июня (видимо, после того как вы начали писать статью).

[antreides]

Спасибо.
Немного непонятно: почему для проверки была взята не стабильная версия OpenJDK 8, а девятая, которая еще в активной разработке, не оттестирована и у которой еще почти год до General Availability? Это даже не бета-версия.

[tagir_valeev]

Так же интереснее!

[SvyatoslavMC]

Ваш проект всё ещё в

в активной разработке

не оттестирован

даже не бета-версия

?

А дальше как в рекламе :D

[gmvbif]

Когда ребята из PVS-Studio берут не свежую версию — им кричат, что надо брать trunk (master) и там все эти баги уже пофикшены.

[EvgeniyRyzhkov]

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

[vanyamasnuha]

Там баги уже выловили вручную. А могли б анализатором.

[AndreyRubankov]

В прошлых статьях (проверка C#, кажется) писали, что Java проверять не интересно, т.к. это не проприетарная платформа.
И вот статья о проверке Java, интересно что повлияло на изменение курса?

[SvyatoslavMC]

Статья о проверке C/C++ проекта. Не могу сказать, что Java совсем не причём, но в прошлых статьях скорее всего писали о проверке проектов именно на языке Java.

[tagir_valeev]

Я думаю, речь шла о проверке Java-кода. А здесь выполняется проверка той части OpenJDK, что написана на C++.

[apangin]

Спасибо! Давно хотелось увидеть анализ OpenJDK.
Признаться, ожидал, что всё будет хуже.

Две, действительно, серьёзные баги (про приоритет "? :" и про sizeof(buf) в printf) к моменту публикации уже были пофикшены, а остальное — просто хорошие замечания, хотя и не влияющие на работоспособность. Каст double* к float* и вовсе не бага, а типичный сценарий переиспользования буфера.

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

[denixx]

Плюс в карму за терморектальный криптоанализатор на второй картинке статьи. Бедная Java…