Comments 8
Всегда интересовало: а после проверки вы открываете PR или issue c найденными проблемами?
Мы всегда уведомляем разработчиков о найденных ошибках. Почему мы сами не делаем Pull Requests для исправления найденных ошибок? Если кратко, то есть 3 причины:
Мы постоянно что-то проверяем. Количество найденных ошибок в открытых проектах давно перевалило за 15000. Если мы будем все их пытаться править, то это надо на постоянную основу брать пару человек, которые только и будут этим заниматься. Пока мы не можем позволить себе такое баловство.
Мы не знакомы с проектом и часто просто не знаем, как править ошибки. Т.е. то что это ошибка, это понятно, а как править — нет.
При написании статей у нас не полноценный, а поверхностный анализ, цель которого популяризация статического анализа кода. Да, какие-то ошибки будут поправлены, но вовсе не все, которые можно обнаружить. Если уж править, то надо подойти к этому серьезно. Это лучше и качественнее сделают разработчики проекта, а не мы. Более того, статический анализ надо использовать регулярно, а не от случая к случаю. Подробнее эта мысль изложена здесь: "Ошибки, которые не находит статический анализ кода, потому что он не используется".
А наоборот пробовали?
Тем же CSA проверить код PVS И опубликовать результаты.
Проверка PVS-Studio с помощью Clang (правда это 2014 год, а потом мы это регулярно делаем).
Фрагмент N3. Если, по вашему предложению, заменить константу на какую-то другую, то выражение станет всегда истинным. Если kind равно ImportKind::Only, то точно не равно чему-то другому.
Возможно. Ничего, разберутся :)
Нестрашна ошибка только из-за везения. Собственно, assert не оказывает заметного влияния на выполнение программы. А в release-версии он вообще превращается в ничто.
Не факт. В нашем проекте кастомный assert, и в релизе срабатывание assert'а вызывает падение всей программы.
Примеры ошибок, которые может обнаружить PVS-Studio в коде LLVM 15.0