Опять уязвимость в этом Линукс

Повторю: речь не о теоретическом соответствии чему-либо, а чисто о решении практической задачи: сделать чтобы компилятор выдавал нужный результат.

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

А я повторю, что gcc обслуживает нужды других GNU проектов в плане их компиляции, а не только свои собственные (тоже в плане компиляции). И именно поэтому, подозреваю, туда добавлялись именно практически полезные фичи в первую очередь, а не педантичная реализация ISO. И появились его первые версии до ISO. Отмазы про «в стандарте этого нету» это вообще отмазы с единственной целью послать подальше желающего ненужной им фичи.

А я повторю, что gcc обслуживает нужды других GNU проектов в плане их компиляции

Тебя обманули. Если посмотришь список коммитеров в GCC, там будут в основном корпораты типа Intel.

И появились его первые версии до ISO.

Я тебе вообще хохму расскажу: первые версии GCC были написаны на… Паскале!

Отмазы про «в стандарте этого нету» это вообще отмазы с единственной целью послать подальше желающего ненужной им фичи.

Ты меня, кажется, неправильно понял (опять). У разработки GCC примерно такие приоритеты:

1. Соответствие стандарту ISO
2. Производительность выдаваемого кода
3. Всё остальное

Тот факт, что выдаваемый код не соответствует ожиданиям некоторых сишников, это исключительно их проблема. Была бы. Но тут есть нюанс в том, что это так для абсолютного большинства сишников, потому что стандарт написан жопой с ручкой. И поэтому C – очень плохой язык. Других программистов вывести гораздо сложнее, чем сделать нормальный язык без вот этого вот всего говна. Можно даже так и назвать его: «С БЕЗ ГОВНА». Убрать нахрен всё UB, сделать поведение ожидаемым и консистентным, мб синтаксис чуток поправить. Нюанс только в том, что такие язычки уже есть, но хардкорные сишники их очень не любят, потому что не Ъ.

Вывод то какой?

Сишка сосёт

Ну даже при наличии языков «лучше Си» она не будет сосать ещё лет 20.

Она уже лет 50 сосёт. Благо, при наличии языков получше её прососы — не моя проблема, по большей части, потому что я могу писать на них.

Например, бесконечный цикл без условий – UB

«Да что ты, чёрт побери, такое несёшь?»

Пункты 6.8.5p4 и 6.8.5.3p2 стандарта читай до просветления. Хинт: for(;;) === for(;true;). Никакого UB.

Например, бесконечный цикл без условий – UB

«Да что ты, чёрт побери, такое несёшь?»

Пункты 6.8.5p4 и 6.8.5.3p2 стандарта читай до просветления. Хинт:for(;;)===for(;true;). Никакого UB.

Ещё один сишник сломался. Но объясни мне вот этот код тогда:

https://godbolt.org/z/Pv1Wqjdfn

Ты разницу между пустым телом цикла и «циклом без условий» не видишь?

Дальнейший тупняк — без меня.

Ты разницу междупустым теломцикла и «циклом без условий» не видишь?

Ты нашу дискуссию тут жопой читал? Мы именно бесконечные циклы без сторонних эффектов тут и обсуждали.

Вообще не читал. Всё, что из неё следует — что ты ещё и разницу между UB и «implementation-specific» не понимаешь (ещё один хинт: 5.1.2.3p4). Что никак не меняет того факта, что вот этот высер:

Например, бесконечный цикл без условий – UB

— чушь собачья.

Вообще не читал.

Не читал но мнение имеешь? Как типично для сишника!

впрочем никак не отменяет того, что делать её UB - это какая-то чушь

Интересно, какой идиот вообще такое придумал? Это же абсурд! Обращаться к уже освобожденной памяти – это однозначная ошибка. Компилятор вообще не должен собирать такой код.

Компилятор, конечно же, обладает встроенным ясновидением, и всегда может узнать, что данный конкретный указатель, переданный в функцию, освобождён в другом модуле, если не в другой библиотеке.

Сегодня парад клоунов, что ли?

Читать надо стандарты, и документацию на конкретный компилятор, в котором описаны особенности реализации (а они могут даже не всегда строго соответствовать стандарту, в эмбеддинге, например). Лоровский тупняк — не надо.

Cтандарт может предусматривать обнуление указателя при вызове free. Стандарт может предусматривать наличие у указателя дополнительных атрибутов, которые позволят однозначно определить, протух ли указатель, или еще нет. На худой конец, стандарт может предотвращать компиляцию совсем очевидного кода вида

char *some_string = malloc(10);
free(some_string);
printf("%s\n", some_string);

Не говоря уже о том, что в Си можно было добавить аннотации. Тогда можно было бы явно указать компилятору, где освобождается память.