Цитата: adolfus от 18.03.2024 02:42:23Отвечал выше, но отвечу еще раз – все случаи UB перечислены в стандарте. Это значит, что любой факт их появления в программе – ошибка программиста. Если вы не будете создавать условий для UB, никаких проблем у вас не будет. Просто почаще в стандарт заглядывайте. Компилятор ЯП не должен анализировать семантику – это исключительная задача программиста, который должен знать, что он делает. И если программист, например, кастует указатель в целое, значит это так и надо. тем не менее, компилятор, конечно же, в этом случае выдаст предупреждение.
Есть такая библиотека – pthreads, так вот в документации четко написано, что многие функции никаких проверок на значения параметров не делают и правильные значения, переданные в вызов, – это ответственность программиста и только его. В этой библиотеке UB на порядок больше, чем в Std ISO/IEC 9899 и никого это не беспокоит.
Значительная часть описанных в стандарте UB уже давно не имеют никакого практического смысла. В 70-х годах их наличие имело причины. В настоящее время этих причин нет. Их можно и нужно тупо вычистить из стандарта, приняв наиболее распространенное поведение за норму.
Например:процессоров с обратным кодом давно не делают.
Везде используется двоичная арифметика в дополнительном коде, никаких оснований сохранять UB на integer overflow - не существует. Если писатели компилятора не заложили специально диверсию (а они это любят, да), то на любом, существующем за пределами музея, процессоре INT_MAX+1 == INT_MIN. У процессора целочисленное переполнение проблем не вызывает. А вот у стандартизаторов - прям беда. Еще можно вспомнить, например, сравнение указателей. Вы в курсе, что сравнение двух указателей между собой - это UB? Алло, 80286 не производятся давно. И уж явно не стоит в 2023 точить стандарт под его причуды.
Таких примеров можно собирать пачками. Одни и те же люди сначала раскидывают по стандарту UB направо и налево, а потом творят дичь в компиляторе, ссылаясь на стандарт. Из свежего в C23:
realloc(p, 0) который всегда был полным аналогом
free(p), вдруг стал UB. Ахиреть не встать.
Да что там говорит, в стандартной библиотеке C до сих пор нет элементарного макроса для определения, является ли целевая платформа big или little-endian, через изврат приходится выяснять. Но зато всякой хероты туда навтыкали, да.
В комитете по C очень мало людей, которые реально программируют на С. Там сидят на всю башку приплюсные писатели GCC и CLang.
Линус как-то емко высказался про стандарт C:
ЦитатаI've said this before, and I'll say it again: a standards paper is
just so much toilet paper when it conflicts with reality. It has
absolutely _zero_ relevance. In fact, I'll take real toilet paper over
standards any day, because at least that way I won't have splinters
and ink up my arse.
https://lkml.org/lkml/2018/6/5/769