Судный день: топ-10 ошибок в C и C++ проектах за 2024 год

[@viordash]

Если кто-нибудь из читателей может подсказать что именно здесь происходит, то добро пожаловать в комментарии.

:) элементарно, это же для кейсов 32¾ , 34¾ и 37¾

[@oldnomad]

Под №2 комментарий подробно объясняет что именно происходит. Поскольку std::getenv() возвращает указатель на строку (или nullptr), он никогда не будет равен (char *)-1 и весь код после if недостижим. Это, конечно же, не решает всех проблем, потому что UB есть UB даже в недостижимом коде, но в данном случае разработчики пошли на риск.

[@KanuTaH]

Это, конечно же, не решает всех проблем, потому что UB есть UB даже в недостижимом коде, но в данном случае разработчики пошли на риск.

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

if (ptr != nullptr) ptr->fn();

Если ptr нулевой, то разыменовывающий его код становится недостижимым, и UB не происходит. Тут нет абсолютно никакого риска до тех пор пока есть уверенность что результат getenv() никогда не может стать равен (char*)-1.

[@Nemoumbra]

О, упомянули PPSSPP! Первый "баг" оттуда. В кавычках, т.к. при отсутствии памяти уже течь нечему)) На практике у нас это не происходит, но я это отдельно спрошу у hrydgard-а, не стоит ли починить. Кстати, вот цитата из статьи про PPSSPP:

В этой статье приведён далеко не весь список обнаруженных ошибок. Поэтому про оставшуюся их часть выйдет отдельная статья.

Надо полагать, это уже в следующем году только ждать? Поскорей бы...)

[@AleksandraUvarova]

Только что опубликовали вторую часть статьи про проверку PPSSPP. Приглашаю к прочтению)

[@eptr]

В №1 забыли написать:

static_assert(std::size(s_status_str) == MAX_DBG_STATUS, "What???");

Такое даже на голом C можно написать, только std::size необходимо заменить на соответствующее.

То есть, механизм-то — есть, но его не применяют.