Комментарии 17
Вопрос не совсем по теме: умеет ли PVS-studio находить ошибки вида
Имеется в виду: (1) возможное деление на ноль и (2) отсутствие проверок в коде на (1)?
Пробная версия, к сожалению, эти места не обнаружила. Если такого функционала нет, я думаю, есть смысл его добавить — подобный код встречается не так уж и редко…
auto average = total / x.size();
?Имеется в виду: (1) возможное деление на ноль и (2) отсутствие проверок в коде на (1)?
Пробная версия, к сожалению, эти места не обнаружила. Если такого функционала нет, я думаю, есть смысл его добавить — подобный код встречается не так уж и редко…
+1
Если выдавать предупреждение на каждое деление, то будет много ложных срабатываний.
Мы сделали так: если выражение в знаменателе было как-то ограничено, например в условии блока if, или это счётчик цикла, который принимает ограниченное количество значений и ноль в него тоже входит, тогда выдаём предупреждение.
Мы сделали так: если выражение в знаменателе было как-то ограничено, например в условии блока if, или это счётчик цикла, который принимает ограниченное количество значений и ноль в него тоже входит, тогда выдаём предупреждение.
+2
В итоге получается, что случай, приведенный мной выше, анализатор пропускает, а при выполнении программы в редких кейсах размер вектора становится равным нулю, и все падает…
Было бы неплохо все же иметь хоть какую-то опцию, вроде «расширенная проверка деления на ноль», по умолчанию отключенную для удобства.
Было бы неплохо все же иметь хоть какую-то опцию, вроде «расширенная проверка деления на ноль», по умолчанию отключенную для удобства.
0
{ return sizeof(Method)/wordSize + (is_native()? 2: 0); }
Вообще разработчики OpenJDK тоже пользуются статическим анализом. Это довольно свежий код и эту багу уже исправили 7 июня (видимо, после того как вы начали писать статью).
+3
Спасибо.
Немного непонятно: почему для проверки была взята не стабильная версия OpenJDK 8, а девятая, которая еще в активной разработке, не оттестирована и у которой еще почти год до General Availability? Это даже не бета-версия.
Немного непонятно: почему для проверки была взята не стабильная версия OpenJDK 8, а девятая, которая еще в активной разработке, не оттестирована и у которой еще почти год до General Availability? Это даже не бета-версия.
+4
Так же интереснее!
+3
НЛО прилетело и опубликовало эту надпись здесь
Когда ребята из PVS-Studio берут не свежую версию — им кричат, что надо брать trunk (master) и там все эти баги уже пофикшены.
+11
Тестировать стабильную версию — самый худший способ применения анализа кода. Лучше чем ничего, но сильно хуже, чем должно быть. На тестирование и отладку стабильной версии УЖЕ было потрачено куча сил. Которые можно было бы сэкономить, если регулярно использовать статический анализ.
+4
Там баги уже выловили вручную. А могли б анализатором.
0
В прошлых статьях (проверка C#, кажется) писали, что Java проверять не интересно, т.к. это не проприетарная платформа.
И вот статья о проверке Java, интересно что повлияло на изменение курса?
И вот статья о проверке Java, интересно что повлияло на изменение курса?
0
Спасибо! Давно хотелось увидеть анализ OpenJDK.
Признаться, ожидал, что всё будет хуже.
Две, действительно, серьёзные баги (про приоритет "? :" и про sizeof(buf) в printf) к моменту публикации уже были пофикшены, а остальное — просто хорошие замечания, хотя и не влияющие на работоспособность. Каст double* к float* и вовсе не бага, а типичный сценарий переиспользования буфера.
Много ли было ложных срабатываний? Подозреваю, что с таким стилем кодирования, как в HotSpot, и с кучей макросов их должно быть просто море.
Признаться, ожидал, что всё будет хуже.
Две, действительно, серьёзные баги (про приоритет "? :" и про sizeof(buf) в printf) к моменту публикации уже были пофикшены, а остальное — просто хорошие замечания, хотя и не влияющие на работоспособность. Каст double* к float* и вовсе не бага, а типичный сценарий переиспользования буфера.
Много ли было ложных срабатываний? Подозреваю, что с таким стилем кодирования, как в HotSpot, и с кучей макросов их должно быть просто море.
+3
Плюс в карму за терморектальный криптоанализатор на второй картинке статьи. Бедная Java…
+3
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Проверка проекта OpenJDK с помощью PVS-Studio