О неопределенном поведении

Нет, если вы также не оставляете свой компилятор прежним и документация вашего компилятора определяет неопределенное поведение.

Неопределенное поведение означает, что ваш компилятор может игнорировать ваш код по любой причине, делая то, что, по вашему мнению, должно быть правдой em> быть.
Иногда это делается для оптимизации, и иногда это связано с такими архитектурными ограничениями.

Я предлагаю вам прочитать это, который относится к вашему точному примеру. Выдержка:

Переполнение целого числа со знаком:

Если арифметика для типа int (например) переполняется, результат не определен. Одним из примеров является то, что INT_MAX + 1 не обязательно будет INT_MIN. Это поведение включает определенные классы оптимизации, которые важны для некоторого кода.

Например, зная, что INT_MAX + 1 не определено, можно оптимизировать X + 1 > X до true. Знание того, что умножение не может переполниться (потому что это было бы неопределенным), позволяет оптимизировать X * 2 / 2 до X. Хотя это может показаться тривиальным, такие вещи обычно обнаруживаются при встраивании и раскрытии макросов. Более важная оптимизация, которую это позволяет, предназначена для циклов <=, подобных этой:

for (i = 0; i <= N; ++i) { ... }

В этом цикле компилятор может предположить, что цикл повторится ровно N + 1 раз, если i не определено при переполнении, что позволяет использовать широкий диапазон оптимизаций цикла. , то компилятор должен предположить, что цикл, возможно, бесконечен (что происходит, если N равно INT_MAX), что затем отключает эти важные оптимизации цикла. Это особенно влияет на 64-битные платформы, так как очень много кода использует int в качестве переменных индукции.

No.

Компилятор использует неопределенное поведение при оптимизации кода. Известным примером является строгая семантика переполнения в компиляторе GCC (найдите strict-overflow здесь) Например, этот цикл

for (int i = 1; i != 0; ++i)
  ...

предположительно полагается на ваше «зависимое от машины» поведение переполнения целочисленного типа со знаком. Однако компилятор GCC в соответствии с правилами строгой семантики переполнения может (и будет) предположить, что увеличение переменной int может только сделать ее больше и никогда не уменьшить. Это предположение заставит GCC оптимизировать арифметику и вместо этого сгенерировать бесконечный цикл.

for (;;)
  ...

поскольку это вполне допустимое проявление неопределенного поведения.

По сути, в языке C нет такого понятия, как «машинно-зависимое поведение». Все поведение определяется реализацией, а уровень реализации — это самый низкий уровень, до которого вы когда-либо могли добраться. Реализация изолирует вас от необработанной машины и изолирует вас идеально. Невозможно прорваться через эту изоляцию и добраться до фактической необработанной машины, если только реализация явно не разрешает вам это делать. Переполнение целого числа со знаком обычно не является одним из тех контекстов, в которых вам разрешен доступ к необработанной машине.

Если вы точно знаете, что ваш код будет нацелен только на определенную архитектуру, компилятор и ОС, и знаете, как работает неопределенное поведение (и что оно не изменится), то нет ничего плохого в том, чтобы использовать его время от времени. В вашем примере, я думаю, я тоже могу сказать, что произойдет.

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

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

В общем, лучше полностью его избегать. С другой стороны, если в документации вашего компилятора явно указано, что эта конкретная вещь, которая является UB для стандарта, вместо этого определена для этого компилятора, вы можете использовать ее, возможно, добавив некоторые механизмы #ifdef/#error для блокировки компиляции в случае использования другого компилятора. .

Если стандарт C (или другого языка) объявляет, что какой-то конкретный код будет иметь Undefined Behavior в какой-то ситуации, это означает, что компилятор C может генерировать код, который делает все, что он хочет в этой ситуации, оставаясь при этом совместимым с этим стандартом< /я>. Многие конкретные языковые реализации имеют задокументированное поведение, выходящее за рамки того, что требуется общим языковым стандартом. Например, компания Whizbang Compilers Inc. может явно указать, что ее конкретная реализация memcpy всегда будет копировать отдельные байты в порядке адресов. В таком компиляторе код вида:

  unsigned char z[256];
  z[0] = 0x53;
  z[1] = 0x4F;
  memcpy(z+2, z, 254);