Как стать автором
Поиск
Написать публикацию
Обновить

Комментарии 19

Ошибка №10 — вот не вижу ошибки, серьезно. p_at_index передается снаружи, может принимать значения от -1 до blend_points_used, где предположительно blend_points_used есть длина массива blend_points (аллоцированная может быть больше). Как следствие, если p_at_index== blend_points_used, выполняется вставка элемента в конец массива, а если где-то в середине, то выполняется сдвиг элементов по массиву в сторону больших индексов до позиции p_at_index, в которую ниже выполняется вставка. И таки да, в этом случае цикл for имеет право не выполниться ни разу…

А, нашел — переменную i нужно инициализировать новым значением последнего индекса массива, которое равно blend_points_used, а там стоит blend_points_used-1. В этом случае цикл отработает минимум один раз, сдвинув последний элемент в позицию [blends_points_used] и освободив место для вставки. Таки CWE в виде потери ссылки на последний объект в списке, хи-хи. Респект! И правильно, цикл должен идти в обратную сторону, т.е. i--. Действительно, вместе взятое получается WTF.
Всего голосов 4: ↑4 и ↓0+4

Если смысл анализатора в предотвращении ошибок ещё до их первого попадания в коммит и раньше, а не выявлении застарелых, то возможно было бы наглядно провести другой эксперимент? Взять 10 последних багфиксов, которые сделали сами авторы без анализатора и показать, могли ли они быть предотвращены с помощью анализатора на раннем этапе?

Всего голосов 2: ↑2 и ↓0+2
Можно, но это сложно и очень нудно. Если хотите, попробуйте провести такой эксперимент сами и поймёте, почему мы таких статей не пишем. :)
Всего голосов 1: ↑1 и ↓0+1
Понимаю, но я не продаю статический анализатор ;). Придется покупателям и дальше верить Вам на слово, когда Вы говорите, что анализатор наиболее полезен для предотвращения ошибок на раннем этапе.
Всего голосов 2: ↑1 и ↓10
Прошло немало времени, пока проверялся проект, пока я готовился к докладу, пока писалась статья, пока она переводилась. Как результат по крайней мере 2 ошибки уже были исправлены. А их могло бы и вообще не быть…
Всего голосов 3: ↑3 и ↓0+3
А разве есть техническая разница в поиске ошибок на раннем этапе и разовых проверках? По-моему, очевидно, что всё нашлось бы при первом применении. Тем более, поведение анализатора детерминировано на одном и том же коде. Нет никаких оснований «брать на веру», весь материал состоит из пруфов)
Всего голосов 1: ↑1 и ↓0+1
Есть, это разные ошибки, о чем говорится в статье. Те ошибки, которые находятся при разовых проверках — это, в основном, несущественные ошибки, с которыми пользователи и тестеры не столкнулись. А вот найдутся ли те ошибки, ради которых потом, с кучей усилий, приходится выпускать багфиксы — не вполне очевидно.
Пруфы в этой статье касаются только первого типа, то есть ошибок не найденных ни тестами ни пользователями, а значит незначительных.
Совершенно не очевидно, что технически (с точки зрения анализатора) «важные» (те, что потом будут обнаружены тестами и пользователями) ошибки и те что в статье — одинаковы.
Вот какой процент багфиксов по-вашему можно избежать применяя PVS-studio?
Всего голосов 2: ↑1 и ↓10
то есть ошибок не найденных ни тестами ни пользователями, а значит незначительных
Очень странное заключение…
Всего голосов 2: ↑1 и ↓10
Вы оба правы. Действительно существую ошибки, которые находятся в неиспользуемом коде. Толку от их нахождения мало, вот только сложно со стороны сказать, является ошибка таковой или нет.

Однако, то что ошибка долго не обнаруживается, не значит, что она несущественна. Возможно, это противный гейзенбаг, который всем досаждает, но который пользователю трудно повторить и описать. В результате, пользователь начинает с меньшим интересом относиться к приложению или вообще просто тихо перестаёт им пользоваться. Ещё один вариант не проявляющей себя ошибки — уязвимость. Их надо искать и править, но пользователь с ними не сталкивается.
Всего голосов 1: ↑1 и ↓0+1
то что ошибка долго не обнаруживается, не значит, что она несущественна.
Не значит, но это очень сильно скоррелированные параметры. Большая часть застарелых ошибок, как вы и сами говорите, несущественны.
Их надо искать и править, но пользователь с ними не сталкивается.
сталкивается тестер, сталкивается пользователь, когда уязвимость кто-то начинает эксплуатировать.
Комментарий пока не оценивали0
это не мое заключение, а заключение автора статьи:
Смысл статического анализа кода не в том, чтобы найти застаревшие ошибки. Эти старые ошибки обычно незначительны, иначе бы они мешали пользователям и их бы уже нашли и исправили.

И дальше идет анализ именно таких застаревших ошибок.
При чем автор и сам осознает проблему:
возникает ложное ощущение, что статические анализаторы находят только какие-то малоинтересные ошибки в редко используемых участках кода. Конечно, так оно и есть, если использовать анализатор неправильно и запускать его только время от времени

Но тем не менее доказательств ложности этого ощущения не приводится, что и понятно, ведь это сложно и нудно.
Всего голосов 2: ↑2 и ↓0+2

Зима уж близится, а всё-таки, как там прогресс по анализатору Java?
Насчет C++ давно понятно, что отстрелить себе ногу там можно тысячами изощрённых способов, как без анализатора, так и с ним вместе.

Всего голосов 2: ↑1 и ↓10
Постепенно рассылаем beta-версии PVS-Studio Java на пробу, работаем с отзывами.
Всего голосов 2: ↑2 и ↓0+2
Кстати говоря, кроме вашей проверки в 2015 году, его ещё относительно недавно в 2017 проверяли
Всего голосов 2: ↑2 и ↓0+2
Противостояние багов и программистов будет вечным, если не обмазаться инструментами контроля качества. Про Google Chromium уже 13 статей написано…
Комментарий пока не оценивали0
Наверное, задам очень банальный вопрос, но вы отправляете авторам open-source проектов патчи с исправлениями после написания таких статей? Было бы очень здорово!
Всего голосов 2: ↑1 и ↓10
Понял, спасибо.
Комментарий пока не оценивали0
Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Ваш аккаунт

Разделы

Информация

Услуги

Техническая поддержка
© 2006–2024, Habr