https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105405
--- Comment #6 from Martin Liška <marxin at gcc dot gnu.org> --- (In reply to Jakub Jelinek from comment #5) > j[5][1].h is 36 after the end of a array, that is definitely too far. Yes. Just a small note that clang emits there a bit bigger red-zone: =>0x0000801c50a0: 00 00 00 00 00 00 00 00 f9 f9 f9 f9 f9[f9]f9 f9 0x0000801c50b0: 04 f9 f9 f9 00 00 00 00 00 00 00 00 00 00 00 00 and thus catches that. > Red zone can be 16 bytes or even less in certain cases (e.g. in the PR105396 > case it is 12 bytes in between d and b variables). > ASan mostly protects against buffer overflows, something accesses the last > byte of a variable, then the byte after it, ... (or similarly the first byte > of a variable, then the byte before it, ...). > -fsanitize=undefined on the other side includes the bounds sanitizer that > verifies array indexes by comparing them against the number of elements the > array has. gcc-11 pr105405.c -fsanitize=undefined && ./a.out pr105405.c:10:13: runtime error: index 1 out of bounds for type 'a [1]'
