Интеркал — самый худший язык программирования из существующих.

это ИМХО баг. Gcc даёт 2 2. Какую «арифметику» тут можно выкинуть?

В стандарте написано, что realloc освобождает память по переданному адресу и возвращает новый объект заданного размера. Использование указателя на освбождённый объект — UB.

Поэтому clang превращает

int main() {
int *p = (int*)malloc(sizeof(int));
int *q = (int*)realloc(p, sizeof(int));
*p = 1;
*q = 2;
if (p == q)
   printf("%d %dn", *p, *q);
}

int main() {
int *p = (int*)malloc(sizeof(int));
int *q = (int*)realloc(p, sizeof(int));
if (p == q)
   printf("%d %dn", 1, 2);
}

Так как других ссылок на *p и *q нет, а друг другу их можно считать неравными по UB.

да. нет там вообще никаких намёков на проверку

Я тебе про это и говорю. Что компилятор превратил код с проверкой на равенство в код без проверки (как бы «всегда равно»).

4.8.0 выкидывает

значит пофиксили.

Можешь попробовать угадать, почему.

не знаю. УМВР. Кстати баг открыт в 2012ом. Наверное, тупо закрыть забыли…

В стандарте написано, что realloc освобождает память по переданному адресу и возвращает новый объект заданного размера.

там написано, что новый объект обязательно по другому адресу?

Использование указателя на освбождённый объект — UB.

действительно, об этом я и не подумал…

Поэтому clang превращает

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

Однако тут ошибка не в самом коде, а в сторонней библиотеке. Да, realloc(3) стандартный, но всё равно, компилятор не должен ИМХО проверять правильность в данном случае. Я уже говорил, что оптимизация идёт _после_ проверок на UB, и тут уж всё.

Я уже говорил, что оптимизация идёт _после_ проверок на UB

Так именно поэтому он и уверен, что *p не алиасит *q. Ведь UB, а значит можно.

Однако тут ошибка не в самом коде, а в сторонней библиотеке. Да, realloc(3) стандартный,

Как раз, если заменить на my_realloc, то ошибка уходит. Так как для внешней функции нет UB.

Тогда зачем вообще нужен стандарт? Отсутствие стандарта тем более позволяет некоторым компиляторам выдать что-то более менее вменяемое.

Чтобы не было ада со стандартами де-факто как gcc С, MSVC С и так далее. Лучше какие-то гарантии будут, чем не будет никаких.

А сейчас, выход за границы массива даже Valgrind'ом не отловить. Потому как компилятор имеет право трактовать a, где i за границами массива как a[0], например. Или вообще как угодно.

Я не защищаю наличие UB. Мне не нравится предложение заменить UB на поток сознания типа «если тут вычитаются указатели на разные массивы, пусть результат будет 42». Не думаю, что такое поведение поможет при отладке.

имеется ввиду, что для выражения x-- - --x; ты в стандарте зафиксируешь какой-то один из трёх возможных вариантов. Т.е. вынудишь компилятор к примеру сначала делать декременты(слева-направо, и никак иначе), потом вычитание. Тогда выражение x-- - --y будет выполнятся не оптимально в 66% платформ, т.к. вариантов тут три, и вероятность правильного выбора ⅓. Сейчас компилятор выбирает правильный путь в 100% случаев, а если получается UB, то выдаёт warning(обычно, да, UB оно такое, по стандарту не обязан).

Компилятор такое UB может обнаружить и сделать не UB, было бы желание. Ну это ладно, так не пишут, может если макросы так развернутся будет проблема, а вот UB с указателями намного хуже.

я не страдаю.

Я не конкретно про ваш код. Вы же не только своими программами пользуетесь.

а вот UB с указателями намного хуже.

ну проблема в том, что реализация указателей везде очень разная даже сейчас. Ну а во времена K&R был вообще ад и израилъ.

Компилятор такое UB может обнаружить и сделать не UB, было бы желание.

а нужно-ли?

.