Какие ошибки есть в коде LLVM?

[datacompboy]

Показывает на качество покрытия тестами. То есть часть эвристик есть, но не покрыто полноценно регрессами... Скорее всего, это практически невозможно, потому и.

[Mingun]

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

Скорее всего результат неудачного разрешения конфликта при мердже. Возможно, даже автоматического. В итого оказалось, что взяли обе половины конфликта.

[slonopotamus]

В общем, интересный случай, когда код написан неправильно, но работает правильно.

Это называется ложное срабатывание.

[AVaTar123]

Да, но только для разработчика, но не анализатора.

[slonopotamus]

Вкусовщина. Я с тем же успехом могу сказать что ошибка разработчика в том что он вообще на C++ пишет. Писал бы на языке где bool не приводится втихаря к int, эта конструкция вообще не скомпилировалась.

[Mingun]

Это называется "мина замедленного действия"

[Okunev_PY]

Не первый раз вижу статьи с анализом чужих продуктов, из этого закономерный вопрос, а можно результаты проверок самой Pvs-Studio увидеть?

[Alphrixus]

Да, например, есть такая статья. А так мы регулярно проверяем сами себя во время ночных сборок на сервере, и разработчикам приходят уведомления на почту, если есть срабатывания.

[sabudilovskiy]

А вы открыли issues в LLVM?

[Alphrixus]

Да, ссылка. Там их уже, кстати, немало от нас :D

[ShaltaiBoltai]

У вас очень полезный продукт и дело вы делаете очень полезное.

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

[Andrey2008]

По разному бывает :) Про игнор вспомнилось - 1000 глаз, которые не хотят проверять код открытых проектов :)

[ShaltaiBoltai]

Я и подозревал, что "по разному бывает". :) Но, например, LLVM - слишком важный проект, чтобы позволить им игнорить ошибки. Особенно такие, которая ниже описана:

И в этом фрагменте забыли явно указать this слева от оператора присваивания.

Или где properties увеличили 2 раза.

И что еще интересно: вы говорите, что код LLVM один из самых удобочитаемых и аккуратных, а параллельно есть мнение, что этот код "один из самых убогих и ненормальных".

[Shermike]

И неспроста. Внутри тела конструктора класса MapLattice произошло сокрытие нестатического поля с тем же именем, что и у параметра. И в этом фрагменте забыли явно указать this слева от оператора присваивания.

В который раз убеждаюсь: LLVM code style один из самых убогих и ненормальных. Как можно додуматься писать имена классов и всех переменных в одном стиле!