Ещё раз о неопределённом поведении или «почему не стоит забивать гвозди бензопилой»

$ cat test.c
int main() {
    int a[4];
    int b[4];
    a[5] = 'a';
    return 0;
}

$ gcc -g -fsanitize=address test.c -otest
$ ./test
=================================================================
==7769==ERROR: AddressSanitizer: stack-buffer-overflow on address 0x7fffefbce234 at pc 0x400803 bp 0x7fffefbce1f0 sp 0x7fffefbce1e8
WRITE of size 4 at 0x7fffefbce234 thread T0
    #0 0x400802 in main /tmp/5/test.c:4
    #1 0x7fcf7202576c in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x2176c)
    #2 0x400668 (/tmp/5/test+0x400668)

Address 0x7fffefbce234 is located in stack of thread T0 at offset 52 in frame
    #0 0x400767 in main /tmp/5/test.c:1

  This frame has 1 object(s):
    [32, 48) 'b' <== Memory access at offset 52 overflows this variable
HINT: this may be a false positive if your program uses some custom stack unwind mechanism or swapcontext
      (longjmp and C++ exceptions *are* supported)
SUMMARY: AddressSanitizer: stack-buffer-overflow /tmp/5/test.c:4 main
Shadow bytes around the buggy address:
  0x10007df71bf0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x10007df71c00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x10007df71c10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x10007df71c20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x10007df71c30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
=>0x10007df71c40: f1 f1 f1 f1 00 00[f4]f4 f3 f3 f3 f3 00 00 00 00
  0x10007df71c50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x10007df71c60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x10007df71c70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x10007df71c80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x10007df71c90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Shadow byte legend (one shadow byte represents 8 application bytes):
  Addressable:           00
  Partially addressable: 01 02 03 04 05 06 07 
  Heap left redzone:       fa
  Heap right redzone:      fb
  Freed heap region:       fd
  Stack left redzone:      f1
  Stack mid redzone:       f2
  Stack right redzone:     f3
  Stack partial redzone:   f4
  Stack after return:      f5
  Stack use after scope:   f8
  Global redzone:          f9
  Global init order:       f6
  Poisoned by user:        f7
  Contiguous container OOB:fc
  ASan internal:           fe
==7769==ABORTING

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

Я действительно не хочу, чтобы компилятор «оптимизировал» блоки кода по принципу «это ж андефайнд, значит будем, считать, что можно делать что угодно».

STL отдельный разговор, могла бы быть исключением. Сотни предупреждений — результат принципа реализации стандартной бибилиотеки как набора шаблонов, макросов. Поскольку это _стандартная_ библиотека, вполне могла бы обрабатываться особо.

STL отдельный разговор, могла бы быть исключением. Сотни предупреждений — результат принципа реализации стандартной бибилиотеки как набора шаблонов, макросов. Поскольку это _стандартная_ библиотека, вполне могла бы обрабатываться особо.

Это вполне может быть настраиваемым. Уровни предупреждений.

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

#include <stdio.h>

int test(int i, int j) {
  return (i + 10 > j + 10);
}

int main(){
  printf("%d\n", test(1073741820, 2147483640));
}

$ clang -O0 test.c -o test0
$ clang -O2 test.c -o test2
$ ./test0
1
$ ./test2
0

Но раз уж компилятор взялся за тяжелую задачу обнаружения UB.

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

А вы разработчик компиляторов?

Хотите задавить авторитетом вместо того, чтобы приводить логические доводы?

People often ask why the compiler doesn't produce warnings when it is taking advantage of undefined behavior to do an optimization, since any such case might actually be a bug in the user code. The challenges with this approach are that it is 1) likely to generate far too many warnings to be useful — because these optimizations kick in all the time when there is no bug, 2) it is really tricky to generate these warnings only when people want them, and 3) we have no good way to express (to the user) how a series of optimizations combined to expose the opportunity being optimized.

Если компилятор видит, что проверки «лишние» — должен быть напечатан варнинг, проверки оставлены.

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

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

Пардон, разве shl в x86 — это восемь инструкций?

Потому что некоторые из них уже ведут себя одинаково!

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

Чем сдвиг хуже?

На Геделя я ссылаюсь потому, что из его теоремы следует