Чем ловить Undefined Behaviour?

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

Следовательно, остаются три способа:

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

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

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

На практике, работает комбинация методов - в процессе написания кода следует держать в голове ситуации "что может пойти не так" и не допускать их, при тестах подавать не только хорошие данные, но и явную подставу, а при помещении в репозитарий скармливать код в Coverity/PVS Studio/Clang, и собирать с самыми жесткими диагностиками.

Дополнительными способами улучшайзинга могут быть:

• отказ от глобальных переменных
• использование как можно большего количества иммутабельных сущностей, повсеместная расстановка const в частности
• Соблюдение RAII, применение только умных указателей
• Список можно дополнять очень многими пунктами, все зависит, в конечном итоге, от бюджета ресурсов на разработку.