Комментарии 5
Если кто-нибудь из читателей может подсказать что именно здесь происходит, то добро пожаловать в комментарии.
:) элементарно, это же для кейсов 32¾ , 34¾ и 37¾
Под №2 комментарий подробно объясняет что именно происходит. Поскольку std::getenv()
возвращает указатель на строку (или nullptr
), он никогда не будет равен (char *)-1
и весь код после if
недостижим. Это, конечно же, не решает всех проблем, потому что UB есть UB даже в недостижимом коде, но в данном случае разработчики пошли на риск.
Это, конечно же, не решает всех проблем, потому что UB есть UB даже в недостижимом коде, но в данном случае разработчики пошли на риск.
UB в недостижимом коде в принципе невозможен. Типичный прием по избеганию UB как раз и состоит в том, чтобы делать соответствующий код недостижимым. Вы пользуетесь этим приемом каждый раз, когда пишете что-нибудь вроде:
if (ptr != nullptr) ptr->fn();
Если ptr
нулевой, то разыменовывающий его код становится недостижимым, и UB не происходит. Тут нет абсолютно никакого риска до тех пор пока есть уверенность что результат getenv()
никогда не может стать равен (char*)-1
.
О, упомянули PPSSPP! Первый "баг" оттуда. В кавычках, т.к. при отсутствии памяти уже течь нечему)) На практике у нас это не происходит, но я это отдельно спрошу у hrydgard-а, не стоит ли починить. Кстати, вот цитата из статьи про PPSSPP:
В этой статье приведён далеко не весь список обнаруженных ошибок. Поэтому про оставшуюся их часть выйдет отдельная статья.
Надо полагать, это уже в следующем году только ждать? Поскорей бы...)
В №1 забыли написать:
static_assert(std::size(s_status_str) == MAX_DBG_STATUS, "What???");
Такое даже на голом C можно написать, только std::size
необходимо заменить на соответствующее.
То есть, механизм-то — есть, но его не применяют.
Судный день: топ-10 ошибок в C и C++ проектах за 2024 год