Вызов никогда не вызываемой функции

Или вы.

Есть возражения на то что компилятор ничего не нарушил?

Есть возражения на то что компилятор ничего не нарушил?

Найдите в том комментарии, на что отвечали, слово компилятор

Ну ты и толстяк. Если таскаешь чужие статьи, то выкладывай их полностью и со ссылкой на оригинал, плиз.

https://kristerw.blogspot.ru/2017/09/why-undefined-behavior-may-call-never.html

новая работа связана с ковырянием потрохов этой песочницы, что неминуемо ведет к изучению c++ кода (на котором она собственно и написана). Зачем это нужно? Да просто у меня пердак горит от c++ ужасов, прочитал немножко кода - и как на войне побывал. Ты не можешь быть уверен ни в чём, никогда, а крупицы уверенности нужно отвоёвывать с боем. Но вариантов слезть с него нет никаких, легаси 20-летней давности никто не перепишет, можно только написать джаву на джаве (см. graalvm), но в самом низу пирамиды будет всё то же самое легаси

Ты не можешь быть уверен ни в чём, никогда, а крупицы уверенности нужно отвоёвывать с боем.

Пример какой-нибудь будет? Или вам приходится иметь дело с C++ным кодом, в котором идут вызовы через неинициализированные указатели?

Тогда main логично изменить на

int main()
{
  if (Do)
    return EraseAll();
  else
    return ((void*)0)();
}

Ну да, логично.

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

Ok. Избавимся от ветки, недопустимой по стандарту, и получим:

int main()
{
  if (Do)
    return EraseAll();
  //else
    //return ((void*)0)(); От этой ветки избавились.
}

Но почему ещё и от условия if(Do) избавились? Оно-то чем не угодило?

Even assignment, comparison with a null pointer constant, or comparison with itself, might on some systems result in an exception.

Ну и выбрасывали бы исключение вместо вызова того, что вызывать не нужно.

Хотя то, что даже сравнение 0 с константой может вызывать исключение на некоторых системах, довольно странно. Код типа

if(ptr==NULL)

можно только написать джаву на джаве

При всём уважении к яве, это будет ужасно: тормоза и утечки памяти в квадрате.

Но почему ещё и от условия if(Do) избавились? Оно-то чем не угодило?

Очевидно, что избавиться от else можно только приняв, что условие в if всегда истинно

написать джаву на джаве

Jikes RVM же

с какого бодуна компилятор решил что там будет адрес функции?

Функция вызывается по указателю — значит указатель не может быть равным нулю.

Ябыстёр.

А мне кажется, что тымедленен.

Ну и выбрасывали бы исключение вместо вызова того, что вызывать не нужно.

Это стандарт С.

Хотя то, что даже сравнение 0 с константой может вызывать исключение на некоторых системах, довольно странно. Код типа

if(ptr==NULL)

вполне обыденный (даже в си++, особенно в ранних его версиях, когда new в случае неудачи не генерило исключение, а возвращало NULL). Поэтому на таких платформах просто не будет работать 90% кода.

Там сказано, что есть valid указатели на функцию и на объект, специальный null-указатель, а так же invalid указатели. Т. к. в стандарте ничего не сказано про тип/размер данных по адресу null указателя, то использование данных по этому адресу аналогично использованию invalid указателя. В тоже время, адресс null указателя нам известен, по-этому его можно использовать в операциях присваивания и сравнения.

Там написано, что сравнение invalid pointer с константой может вызвать исключение. А не сравнение null pointer с константой. Лол.

При всём уважении к яве, это будет ужасно: тормоза и утечки памяти в квадрате.

текущий прототип как минимум не медленней, чем нативная джава. А в некоторых случаях - сильно быстрее. В том числе из-за убер-агрессивных оптимизаций, недоступных в классической реализации.

Там написано, что сравнение invalid pointer с константой может вызвать исключение. А не сравнение null pointer с константой.

Сорри, невнимательно прочитал. Но тогда numas13 вообще непонятно к чему это процитировал, явно не в рамках данного треда.

При всём уважении к яве, это будет ужасно: тормоза и утечки памяти в квадрате.

текущий прототип как минимум не медленней, чем нативная джава. А в некоторых случаях - сильно быстрее. В том числе из-за убер-агрессивных оптимизаций, недоступных в классической реализации.

Т. е. у вас какая-то своя собственная реализация явы? А выкладывать/продавать её вы планируете или может даже уже? Или только для внутреннего использования?

Сам я с явой имел дело недолго и очень давно: тогда ещё самой свежей была ява2. Впечатления двойственные: насколько красивым мне покался язык и библиотеки, настолько ужасной была реализация, что проявлялось в скорости работы и в утечках памяти в т. ч. Netbeans IDE, написанной на яве (тоже нативной).

После этого с явой дел не имел, но недавно общался с одним дипломником, который подтвердил, что и сейчас ява дико тормозит.

всё опенсорцнуто, можно гонять тесты уже сейчас: https://github.com/graalvm/graal

Netbeans IDE

я когда-то в ней не смог открыть ни один проект, кроме хэлловорлдов, ибо чудовище распухало и висло. Пришлось выбросить на помойку. Говорят, многие годы спустя его всё-таки починили, и оно даже чем-то славно (типа хорошей интеграцией с Maven), но репутация безнадежно испорчена

Ну и выбрасывали бы исключение вместо вызова того, что вызывать не нужно.

Это стандарт С.

В си тоже есть исключения setjmp/longjmp.

Там сказано, что есть valid указатели на функцию и на объект, специальный null-указатель, а так же invalid указатели. Т. к. в стандарте ничего не сказано про тип/размер данных по адресу null указателя, то использование данных по этому адресу аналогично использованию invalid указателя. В тоже время, адресс null указателя нам известен, по-этому его можно использовать в операциях присваивания и сравнения.

Имхо, это уже какая-то собственная вольная трактовка стандарта.

Но почему ещё и от условия if(Do) избавились? Оно-то чем не угодило?

Очевидно, что избавиться от else можно только приняв, что условие в if всегда истинно

Но, как мы увидели, оно не истинно. А значит это баг компилятора, а не фича стандарта.

Из инструкции Do() выводится что Do != 0.

И этот вывод неверный.

В коде UB, другими словами баг. Компилируя с оптимизациями автор подписывается под фактом, что любые ошибки в коде могут привести к непредсказуемым последствиям. И неважно был ли это вызов нулевой функции, либо непроинициализированная переменная tmp_dir: system((string("rm -rf ") + tmp_dir + "/").c_str()). В последнем случае UB нет, хотя результат тот же, но причина в обоих баг в коде, который обязан быть исправлен автором.

Как уже сказали, компилятор выбросил условие if(Do), потому что при нулевом указателе это UB, а значит корректно должна работать только положительная ветка. Условие не может выполниться отрицательно, это полностью на ответственности автора программы.

Другое дело, что компилятор может подсказывать, когда в программе заранее есть UB, соптимизированное на этапе компиляции. Пусть даже в малочитабельном виде, но автор должен видеть, что программа будет работать не так как задумывалась.

Верный. По правилу Modus tollens.

Верный. По правилу Modus tollens.

Да плевать, по какому правилу. Если я говорю, что крокодилы летают, то какие бы умные правила и логичные рассуждения я ни использовал, — это неверно, потому что не соответствует действительности.

Garbage in, garbage out. А алгоритм вывода верный.

Другое дело, что компилятор может подсказывать, когда в программе заранее есть UB, соптимизированное на этапе компиляции. Пусть даже в малочитабельном виде, но автор должен видеть, что программа будет работать не так как задумывалась.

Почти полностью согласен. Подправлю только самую малость:

Другое дело, что компилятор может должен подсказывать, когда в программе заранее есть UB, соптимизированное на этапе компиляции, если он считает возможным оптимизировать код таким образом, что логика может измениться. Пусть даже в малочитабельном виде, но автор должен видеть, что программа будет работать не так как задумывалась.

всё опенсорцнуто, можно гонять тесты уже сейчас: https://github.com/graalvm/graal

Но в сорцах я не вижу си/си++ кода, только яву. Или это уже ява, переписанная на яве? Тогда о каком си++, используемом в проекте, шла речь?

И, если не секрет, почему GPL2? Ведь GPL3 уже давно есть. Мне-то без разницы, просто интересно, чем 3-я версия не устроила.

Garbage in, garbage out. А алгоритм вывода верный.

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

А если я вместо printf случайно напишу prinf, компилятор тоже вместо сообщения об ошибке должен подставить рандомную функцию, по принципу garbage in, garbage out?

Чтобы запуститься, граалю нужна классическая жаба. Он использует оттуда базовые вещи типа ядра виртуальной машины, низкоуровневой части jit-компилятора, сборщик мусора. А класическая жаба написана на C++.

(Сразу предупреждая гнусные инсинуации: пока коммитов от меня нет, там только чтобы понять что происходит в каком-то конкретном фронте работ минимум полгода надо (но можно невозбранно писать документацию).

почему GPL2?

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

компилятор должен не просто генерить мусор, а ещё и указывать программисту на его ошибки по возможности

для таких случаев в стандарте есть специальный термин: ill-formed. Забавно, что даже тут «компания угондошена» (в терминологии Платова): существуют ill-formed, которым в явном виде разрешено быть не диагностируемыми компилятором (конкретные примеры не помню, но они есть).

по-моему вам уже стоит перестать терять время, и перейти от рассуждений к прямым оскорблениям и нанесению тяжких телесных авторам стандарта

конкретные примеры не помню

inline-функция, определённая по-разному в разных translation units.

и нанесению тяжких телесных авторам стандарта

Да всё в порядке со стандартом. Нужно просто, чтобы по-умолчанию генерировались ошибки при детекте UB на этапе компиляции. У меня долгие годы стойкое ощущение, что я чего-то недопонимаю в компиляторах. Они должны воспринимать подобные «оптимизации» с применением UB как ошибку и ругаться матом.

Вон в той же Java UB исключили как термин из языка. И всем счастие, везде одни исключения и ругательства компилятора.

Имхо, это уже какая-то собственная вольная трактовка стандарта.

[url=]http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1548.pdf

6.5.3.2 Address and indirection operators

...

If an invalid value has been assigned to the pointer, the behavior of the unary * operator is undefined. 102)

102) ...

Among the invalid values for dereferencing a pointer by the unary * operator are a null pointer, ...

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

По возможности он это и так делает, ты же не думаешь что на это специально забивают? Это важнейшее конкурентное преимущество.

Но компиляция, а особенно оптимизация - это трэш и угар. Отследить UB и исключить при этом false positive часто просто нереально. Поэтому и появился рантаймовый UB sanitizer.

Но в этом коде нет UB на этапе компиляции. Поэтому что хотят всякие анскильные лалки от компилятора — непонятно.

кроме следования стандартам здорово когда компилятор подсказывает программисту его факапы

Мне кажется, что здесь и была произведена такая попытка.

Ты не можешь быть уверен ни в чём, никогда

Если не знаешь стандарт, то да, пишешь что-то и надеешься, что это работает. Ну или просто изучаешь инструмент нормально, и не полагаешься на UB. И не обязательно учить _весь_ стандарт наизучть, там половина для language lawyers, об этом сам Бьёрн пишет.

If an invalid value has been assigned to the pointer, the behavior of the unary * operator is undefined

undefined - это значит, что оператор может сотону скастовать, сегфолтнуться, током ударить, или еще что-то сделать. По русски это должно переводиться как «за последствия не отвечаем». А считать undefined = не может быть никогда неверно. undefined - после этой точки может произойти что угодно. в x86 полно undefined - например вот этот бит eflags после такой-то инструкции undefined означает, что там может хранить что угодно, а не то что данная инструкция взорвёт процессор

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

Он это и делает, по возможности. Например,

int x;
int y = x; // UB

такой код, обычно, вызывает warning, хотя типичное UB.

А если я вместо printf случайно напишу prinf, компилятор тоже вместо сообщения об ошибке должен подставить рандомную функцию, по принципу garbage in, garbage out?

А это не UB (предполагается, что такой функции нет в области видимости), поэтому не должен.

в нашем конкретном случае компилятор вообще окуел

у нас Do = null или &EraseAll в зависимости от внешнего условия.

оба значение определены стандартом, никакого undefined значения там нету. компилятор не имеет права, не зная точно что «внешнее условие» равно true или false, выбрать одно из возможных значений как единственно возможное. он должен считать значение Do неизвестным на момент компиляции.

во-вторых, undefined это означает «за последствия не отвечаем». например будет сегфолт, исключение #PF, обычное обращение к оперативке. undefined позволяет ряд оптимизаций, но оптимизации не должны нарушать логику программы. но undefined почему-то положили оправданием для его расползания на соседние операции. то есть если мы обратились на строке 7500 к такой переменной, то компилятор имеет право колбасить везде где хочет. Наконец, UB не должно проходить сквозь контрольные точки: вход и выход из функции, точки ветвления и т.д. машинный код в этом случае полностью прекращает отражать написанное в программе.

у нас Do = null или &EraseAll

Вызов никогда не вызываемой функции (комментарий)

не выводится. из Do() от неконстантного адреса должен выводиться косвенный вызов функции. и всё. вы утверждаете, что undefined = can never happen. нет. undefined здорового человека = последствия не определены. последствия. у курильщика конечно да, еще и предшествующие события могут быть неопределены. курение - зло.

не выводится.

Укажи ошибку в рассуждениях.

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

0 - допустимый адрес. nullptr != 0. можно использовать ~0u как nullptr, он отлично будет крахаться.

Мне кажется, кто-то ничего не понимает ни про то, как работают совеременные компиляторы, ни про UB.

Компилятор может оптимизировать программу не заботясь о том, насколько логичной она будет в случае UB. Поэтому компилятор думает так: в случае UB я могу делать все, что хочу (в т.ч. могу вызвать любую функцию), в противном случае я должен делать то, что указано. Компилятор явно видит, что Do инициализируется только в одном месте, поэтому выдает такоей код:

EraseAll();

и это нормально, т.к. если Do инициализирован, то только EraseAll() (других вариантов нет), если неинициализирован, то можно делать все, что угодно, в .т.ч. вызвать эту функцию.

В итоге в любом случае, код соответствует стандарту.

Что за бессвязный поток сознания? Я просил указать на ошибку в рассуждениях.

nullptr != 0

https://wandbox.org/permlink/LBRhdRAFXzDwcHtu

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

Мне кажется, что именно здесь кроется самое важное. В любой книге по си говорится, что программист сам отвечает за корректность программы. А то, на что он может рассчитывать — описано в стандарте. В данном случае разработчики компилятора решили, что такая ошибка программиста может быть случайной и исправили её как могли.

А значит это баг компилятора, а не фича стандарта.

Так как вызов (void*)0 это UB, то можно натянуть сову на глобус и сказать что else тоже вызывает EraseAll, хотя конечно дружественнее было бы вставить туда builtin_trap

В любой книге по си говорится, что программист сам отвечает за корректность программы

А в других языках кто-то другой отвечает за корректность программы?