https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107696
--- Comment #3 from Martin Liška <marxin at gcc dot gnu.org> ---
So here again depends on the order of stack variables and a[4] is a valid
access to 'b' variable, see what happens with a[6]:
=================================================================
==6539==ERROR: AddressSanitizer: stack-buffer-overflow on address
0x7fffffffd5f8 at pc 0x000000401291 bp 0x7fffffffd590 sp 0x7fffffffd588
WRITE of size 4 at 0x7fffffffd5f8 thread T0
#0 0x401290 in main (/home/marxin/Programming/testcases/a.out+0x401290)
#1 0x7ffff762c5af in __libc_start_call_main (/lib64/libc.so.6+0x275af)
#2 0x7ffff762c678 in __libc_start_main_impl (/lib64/libc.so.6+0x27678)
#3 0x4010c4 in _start ../sysdeps/x86_64/start.S:115
Address 0x7fffffffd5f8 is located in stack of thread T0 at offset 72 in frame
#0 0x4011a5 in main (/home/marxin/Programming/testcases/a.out+0x4011a5)
This frame has 2 object(s):
[48, 52) 'a' (line 3)
[64, 72) 'b' (line 2) <== Memory access at offset 72 overflows this
variable
HINT: this may be a false positive if your program uses some custom stack
unwind mechanism, swapcontext or vfork
(longjmp and C++ exceptions *are* supported)
SUMMARY: AddressSanitizer: stack-buffer-overflow
(/home/marxin/Programming/testcases/a.out+0x401290) in main
Shadow bytes around the buggy address:
0x10007fff7a60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x10007fff7a70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x10007fff7a80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x10007fff7a90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x10007fff7aa0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
=>0x10007fff7ab0: 00 00 00 00 00 00 f1 f1 f1 f1 f1 f1 04 f2 00[f3]
0x10007fff7ac0: f3 f3 00 00 00 00 00 00 00 00 00 00 00 00 00 00
