Комментарии 14
Показывает на качество покрытия тестами. То есть часть эвристик есть, но не покрыто полноценно регрессами... Скорее всего, это практически невозможно, потому и.
А затем приходит понимание, что тернарный оператор здесь вообще не нужен. Возможно, когда-то этот фрагмент был в цикле. Напишите ваши варианты в комментариях.
Скорее всего результат неудачного разрешения конфликта при мердже. Возможно, даже автоматического. В итого оказалось, что взяли обе половины конфликта.
В общем, интересный случай, когда код написан неправильно, но работает правильно.
Это называется ложное срабатывание.
Не первый раз вижу статьи с анализом чужих продуктов, из этого закономерный вопрос, а можно результаты проверок самой Pvs-Studio увидеть?
Да, например, есть такая статья. А так мы регулярно проверяем сами себя во время ночных сборок на сервере, и разработчикам приходят уведомления на почту, если есть срабатывания.
А вы открыли issues в LLVM?
Да, ссылка. Там их уже, кстати, немало от нас :D
У вас очень полезный продукт и дело вы делаете очень полезное.
Я так подозреваю, что для всех публичных продуктов с открытым исходным кодом, что вы проверяете, вы также создаете issues в github. Было бы интересно, если бы вы в статьях также рассказывали, какая есть реакция на созданные вами issues - правятся ли те ошибки, что вы находите, или же ваши предложения игнорируют.
По разному бывает :) Про игнор вспомнилось - 1000 глаз, которые не хотят проверять код открытых проектов :)
Я и подозревал, что "по разному бывает". :) Но, например, LLVM - слишком важный проект, чтобы позволить им игнорить ошибки. Особенно такие, которая ниже описана:
И в этом фрагменте забыли явно указать this слева от оператора присваивания.
Или где properties увеличили 2 раза.
И что еще интересно: вы говорите, что код LLVM один из самых удобочитаемых и аккуратных, а параллельно есть мнение, что этот код "один из самых убогих и ненормальных".
И неспроста. Внутри тела конструктора класса MapLattice произошло сокрытие нестатического поля с тем же именем, что и у параметра. И в этом фрагменте забыли явно указать this слева от оператора присваивания.
В который раз убеждаюсь: LLVM code style один из самых убогих и ненормальных. Как можно додуматься писать имена классов и всех переменных в одном стиле!
Какие ошибки есть в коде LLVM?