Получение аккуратного определения статически выводимой логической ошибки

Я не знаю, возможно ли то, что я хотел бы, но я все равно задаю вопрос.

У меня есть некоторый код библиотеки Boost, в котором я хотел бы дать подсказку clang-tidy выдать предупреждение, где при статическом анализе может произойти явный случай неопределенного поведения из-за плохой логики. https://akrzemi1.wordpress.com/2016/12/12/concealing-bugs/ предполагает, что __builtin_unreachable() может привести в порядок поездку вот так, но мне не удалось это осуществить (хотя это очень хорошо отключает дезинфицирующее средство UB):

#include <optional>

int main()
{
std::optional<int> f;
// Spot the UB before it happens and flag it
if(!f)
{
__builtin_unreachable();
}
// Here is the UB
return *f;
}

В приведенном выше коде статический анализатор может четко сказать, что __builtin_unreachable() должен быть назван. Я хочу, чтобы Clang-Tidy сообщил об этом, но пока clang-tidy-5.0 -checks=* -header-filter=.* temp.cpp -- -std=c++17 ничего не сообщает.

Примечание, мне не нужно использовать __builtin_unreachable(), это как раз то, что предложил Andrzej’s C ++ Blog. любой метод получения статического анализатора clang, статического анализатора MSVC или, в идеале, clang-tidy, для вывода, когда UB, очевидно, должен происходить посредством статического дедукции и пометки его во время компиляции, — это то, что я ищу.

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

Заранее спасибо!

1

Решение

Так что, да, оказывается, что это не может быть сделано, по крайней мере, clang-tidy, и, вероятно, большинство других статических анализаторов.

Мрачные детали почему не могут быть найдены в https://lists.llvm.org/pipermail/cfe-dev/2017-June/054120.html, но по сути:

  1. Проблема остановки, т.е. не знаю, выполняются ли и как циклы.
  2. clang-tidy и другие анализаторы созданы для того, чтобы максимально не видеть мертвый код. Это в точности противоположно тому, что необходимо для проверки выше.
0

Другие решения

Других решений пока нет …