Similar to PR 54691, GCC built with -faddress-sanitizer leads to ==7876== ERROR: AddressSanitizer heap-buffer-overflow on address 0x7f3484513ff0 at pc 0x1e792db bp 0x7fffbed86340 sp 0x7fffbed86338 READ of size 16 at 0x7f3484513ff0 thread T0 #0 0x1e792da (/export/build/gnu/gcc-asan/build-x86_64-linux/gcc/cc1+0x1e792da) 0x7f3484513ff0 is located 0 bytes to the right of 4021-byte region [0x7f3484513040,0x7f3484513ff5) allocated by thread T0 here: #0 0x1f2d48c (/export/build/gnu/gcc-asan/build-x86_64-linux/gcc/cc1+0x1f2d48c) #1 0x1f2609c (/export/build/gnu/gcc-asan/build-x86_64-linux/gcc/cc1+0x1f2609c) Shadow byte and word: 0x1fe6908a27fe: 5 0x1fe6908a27f8: 00 00 00 00 00 00 05 fb [hjl@gnu-tools-1 gcc]$ addr2line -e cc1 0x1e792da /export/gnu/import/git/sources/gcc/libcpp/lex.c:393 [hjl@gnu-tools-1 gcc]$ All search_line_fast implementations read beyond buffer.
>All search_line_fast implementations read beyond buffer. Yes and this is one of the false positives really. We might read past the bounds of an array but it is always on an aligned location and not really depends on those reads past the bounds.
Author: jakub Date: Mon Dec 3 17:19:47 2012 New Revision: 194102 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=194102 Log: PR bootstrap/55380 PR other/54691 * files.c (read_file_guts): Allocate extra 16 bytes instead of 1 byte at the end of buf. Pass size + 16 instead of size to _cpp_convert_input. * charset.c (_cpp_convert_input): Reallocate if there aren't at least 16 bytes beyond to.len in the buffer. Clear 16 bytes at to.text + to.len. Modified: trunk/libcpp/ChangeLog trunk/libcpp/charset.c trunk/libcpp/files.c