А вы знаете, что такое illegal instruction?
Вот я теперь знаю.
Если написать вот так:

bool my_function()
{
   ... // тут не важно что
       // и вот тут не поставлен return
}

То при выходе из функции сгенерится исключение illegal instruction,
и программа упадёт в Core Dump.

А раньше было неопределённое поведение.
Вот. Наткнулся.

Здравствуйте, alpha21264, Вы писали:

A>А раньше было неопределённое поведение.

А компилятор наверняка тебя предупредил!

Здравствуйте, alpha21264, Вы писали:


A>То при выходе из функции сгенерится исключение illegal instruction,
A>и программа упадёт в Core Dump.

А> раньше было неопределённое поведение.

gcc туда лепит UD2

https://mudongliang.github.io/x86/html/file_module_x86_id_318.html

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

Здравствуйте, alpha21264, Вы писали:

A>То при выходе из функции сгенерится исключение illegal instruction,
A>и программа упадёт в Core Dump.

Или не сгенерируется и не упадет, а вернет что-то рандомное.

A>А раньше было неопределённое поведение.

Ничего не поменялось.

Здравствуйте, Pzz, Вы писали:

A>>То при выходе из функции сгенерится исключение illegal instruction,
A>>и программа упадёт в Core Dump.

А>> раньше было неопределённое поведение.

Pzz>gcc туда лепит UD2

Таки да. Сам видел.

Pzz>https://mudongliang.github.io/x86/html/file_module_x86_id_318.html

Pzz>Теперь у нас неопределенное поведение с аппаратным ускорением реализуется, а не абы как.

Теперь оно стало определённым — Core Dump.
А до этого программа нормально работала — возвращаемое значение просто не использовалось.

Здравствуйте, Nuzhny, Вы писали:

A>>А раньше было неопределённое поведение.

N>А компилятор наверняка тебя предупредил!

Типа да. Но он сейчас стал таким занудным — на трёх экранах бессмысленной выдачи я это сообщение просмотрел.

Здравствуйте, alpha21264, Вы писали:

A>А вы знаете, что такое illegal instruction?
Бывает. Если не под ту архитектуру собрать. Или исполняемый файл изменить рандомно. Или ODR нарушить неудачно.

A>

A>bool my_function()
A>{
A>   ... // тут не важно что
A>       // и вот тут не поставлен return
A>}
A>

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

Здравствуйте, alpha21264, Вы писали:


A>А вы знаете, что такое illegal instruction?
A>Вот я теперь знаю.
A>Если написать вот так:

A>

A>bool my_function()
A>{
A>   ... // тут не важно что
A>       // и вот тут не поставлен return
A>}
A>

A>То при выходе из функции сгенерится исключение illegal instruction,
A>и программа упадёт в Core Dump.

A>А раньше было неопределённое поведение.
A>Вот. Наткнулся.

Здорово. Правда?

Здравствуйте, Nuzhny, Вы писали:

N>А компилятор наверняка тебя предупредил!
Любопытно, а почему это не является ошибкой компиляции? В чём смысл генерировать невалидный бинарик, падающий во время исполнения, если уже известно, что в исходнике ошибка?

Здравствуйте, ·, Вы писали:

·>Здравствуйте, Nuzhny, Вы писали:

N>>А компилятор наверняка тебя предупредил!
·>Любопытно, а почему это не является ошибкой компиляции? В чём смысл генерировать невалидный бинарик, падающий во время исполнения, если уже известно, что в исходнике ошибка?

Если эта функция нигде не вызывается, то это не ошибка. Ваш Кэп.

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

Здравствуйте, Chorkov, Вы писали:

C>·>Любопытно, а почему это не является ошибкой компиляции? В чём смысл генерировать невалидный бинарик, падающий во время исполнения, если уже известно, что в исходнике ошибка?
C>Если эта функция нигде не вызывается, то это не ошибка. Ваш Кэп.
Ну даже формально оно всё равно же может падать. UB же. Например, загружается код в exec-секцию какого-то умного процессора и инвалидные инструкции вызовут падение, даже без их выполнения.

C>Возможно, адрес функции как-то используется, даже без вызовов, например, как уникальный идентификатор, или как блокировщик выбрасывания не используемых единиц трансляции.
Если так, то это либо всё равно UB (и потенциальное падение), либо тело функции вообще не компилируется, а создаётся только адрес. Ну тогда ладно, пусть такое не будет ошибкой компиляции, но тогда и сабжа не будет.

C>Или как static_assert, что содержащейся в ней код — компилируемый.
По-моему "компилируемый" должно означать — порождающий некий машкод, а не сабж.

Здравствуйте, kov_serg, Вы писали:

A>>То при выходе из функции сгенерится исключение illegal instruction,
A>>и программа упадёт в Core Dump.

A>>А раньше было неопределённое поведение.

_>Здорово. Правда?

Не знаю, мне не понравилось.
Программа прекрасно работала несколько лет и при переходе на новый кумпилятор стала падать.

Здравствуйте, ·, Вы писали:

N>>А компилятор наверняка тебя предупредил!
·>Любопытно, а почему это не является ошибкой компиляции? В чём смысл генерировать невалидный бинарик, падающий во время исполнения, если уже известно, что в исходнике ошибка?

Возвращаемое значение просто не использовалось и программа работала. Уж мог бы догадаться! В смысле — компилятор.

Здравствуйте, alpha21264, Вы писали:

A>·>Любопытно, а почему это не является ошибкой компиляции? В чём смысл генерировать невалидный бинарик, падающий во время исполнения, если уже известно, что в исходнике ошибка?
A>Возвращаемое значение просто не использовалось и программа работала. Уж мог бы догадаться! В смысле — компилятор.
Ну мне кажется, что было бы разумнее, если бы упало на этапе компиляции с ошибкой, чем вот так. Но это же плюсы: сгенерить заведомо сломаный машкод и пожелать удачи — это норма!

Здравствуйте, ·, Вы писали:

·>Здравствуйте, Nuzhny, Вы писали:

N>>А компилятор наверняка тебя предупредил!
·>Любопытно, а почему это не является ошибкой компиляции? В чём смысл генерировать невалидный бинарик, падающий во время исполнения, если уже известно, что в исходнике ошибка?

компилятор всё равно превращает

int foo(){
  return 0;
}

void main() {
  int i = foo()
}

во что-то такое

void foo(int* ret) {
  *ret = 0;
}

void main() {
  int i;
  foo(&i);
}

так что есть return или нет — на работоспособность никак не влияет. Программист точно также может забыть сделать *ret = 0 во втором коде, как и в первом не вызвать return. Ошибка одного порядка. Второй код — это UB, но вполне корректный с точки зрения синтаксиса. И у первого поведение должно быть идентичное.

Ещё представим, что функция foo и main разнесены по разным единицам трансляции. Компилятор смотрит на оба куска кода и они ему кажутся отдельно вполне корректными. UB то произойдёт на этапе использования неинициализированной переменной. А проинициализирована переменная или нет, компилятор понять не может.

void foo(int* ret) {
  //*ret = 0;
}

void main() {
  int i;
  foo(&i);
  printf("%i", i);
}

Здравствуйте, sergii.p, Вы писали:

SP>компилятор всё равно превращает
Неважно что там внутре компилятора. С т.з. исходного кода там именно return.


SP>так что есть return или нет — на работоспособность никак не влияет. Программист точно также может забыть сделать *ret = 0 во втором коде, как и в первом не вызвать return. Ошибка одного порядка.
Если не влияет, откуда тогда сабж? Как компилятор умудрился сгенерить illegal instruction и зачем?
Могу предоложить лишь ситуацию, когда код unreachable:

bool f() {
  if(inFactAlwaysTrue()) {
    return true;
  }
//never getting here, never crashing
}

вот наверное тут будет не очень хорошо с т.з. совместимости кидать ошибку компиляции.

Здравствуйте, ·, Вы писали:

N>>А компилятор наверняка тебя предупредил!
·>Любопытно, а почему это не является ошибкой компиляции?

А что делать компилятору вот в такой ситуации:

int calculate_something(calc_params & params) {
  if(is_valid_params(params)) {
    ... // Что-то делаем.
    return calculated_result;
  }

  react_to_invalid_input(make_params_description(params));
}

Где react_to_invalid_params реализован в какой-то внешней библиотеке приблизительно таким образом:

void react_to_invalid_params(const std::string & description) {
  ... // Что-то делаем, типа логирования, отсылки писем в Спортлото и лигу сексу...
  std::abort();
}

И написан react_to_invalid_params еще тогда, когда про [[noreturn]] никто и не заикался.

Здравствуйте, so5team, Вы писали:

S>А что делать компилятору вот в такой ситуации:
Я бы выдал ошибку компиляции и заставил поправить исходник, добавив явное

S>  react_to_invalid_input(make_params_description(params));
std::abort(); // это
S>}

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

S>И написан react_to_invalid_params еще тогда, когда про [[noreturn]] никто и не заикался.
Но это, конечно не backward compatible.. так что вряд ли кто-то на такое пойдёт. Остаётся только грустить...

Здравствуйте, alpha21264, Вы писали:


A>Типа да. Но он сейчас стал таким занудным — на трёх экранах бессмысленной выдачи я это сообщение просмотрел.

Дык сборка должна быть warning free (-Werror, /WX) — как раз чтобы не терять важное среди "трёх экранов бессмысленной выдачи".

Здравствуйте, Chorkov, Вы писали:


C>Если эта функция нигде не вызывается, то это не ошибка. Ваш Кэп.

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