[Bug sanitizer/79572] [6/7 Regression] reference binding to null pointer not reported with -fsanitize=undefined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79572 --- Comment #13 from Jakub Jelinek --- Author: jakub Date: Fri Mar 31 18:39:25 2017 New Revision: 246621 URL: https://gcc.gnu.org/viewcvs?rev=246621=gcc=rev Log: PR c++/79572 * c-ubsan.h (ubsan_maybe_instrument_reference): Change argument to tree *. * c-ubsan.c (ubsan_maybe_instrument_reference): Likewise. Handle not just NOP_EXPR to REFERENCE_TYPE, but also INTEGER_CST with REFERENCE_TYPE. * cp-gimplify.c (cp_genericize_r): Sanitize INTEGER_CSTs with REFERENCE_TYPE. Adjust ubsan_maybe_instrument_reference caller for NOP_EXPR to REFERENCE_TYPE. * g++.dg/ubsan/null-8.C: New test. Added: trunk/gcc/testsuite/g++.dg/ubsan/null-8.C Modified: trunk/gcc/c-family/ChangeLog trunk/gcc/c-family/c-ubsan.c trunk/gcc/c-family/c-ubsan.h trunk/gcc/cp/ChangeLog trunk/gcc/cp/cp-gimplify.c trunk/gcc/testsuite/ChangeLog
[Bug sanitizer/79572] [6/7 Regression] reference binding to null pointer not reported with -fsanitize=undefined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79572 --- Comment #12 from Jakub Jelinek --- Created attachment 41029 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41029=edit gcc7-pr79572.patch Untested fix.
[Bug sanitizer/79572] [6/7 Regression] reference binding to null pointer not reported with -fsanitize=undefined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79572 --- Comment #11 from Jakub Jelinek --- Started with r230365, difference in *.original is: - foo ((const int &) (UBSAN_NULL (0B, 2B, 4);, 0B)) >; + foo (0) >;
[Bug sanitizer/79572] [6/7 Regression] reference binding to null pointer not reported with -fsanitize=undefined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79572 Richard Biener changed: What|Removed |Added Priority|P3 |P2
[Bug sanitizer/79572] [6/7 Regression] reference binding to null pointer not reported with -fsanitize=undefined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79572 --- Comment #10 from janus at gcc dot gnu.org --- (In reply to janus from comment #9) > But at least clang 3.9 has some additional diagnostics: > > null_ref.cpp:11:5: warning: binding dereferenced null pointer to reference > has undefined behavior [-Wnull-dereference] > f(*((int*) NULL)); > ^~ > > Ideally GCC should yield the same warning See PR 16351. Lately GCC seems to have a -Wnull-dereference flag as well, but apparently it fails on the test case here.
[Bug sanitizer/79572] [6/7 Regression] reference binding to null pointer not reported with -fsanitize=undefined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79572 --- Comment #9 from janus at gcc dot gnu.org --- (In reply to Richard Biener from comment #8) > Btw, clang behaves the same: True. But at least clang 3.9 has some additional diagnostics: null_ref.cpp:11:5: warning: binding dereferenced null pointer to reference has undefined behavior [-Wnull-dereference] f(*((int*) NULL)); ^~ Ideally GCC should yield the same warning, and maybe even turn it into an error with -std=c++14, as opposed to -std=gnu++14 ?
[Bug sanitizer/79572] [6/7 Regression] reference binding to null pointer not reported with -fsanitize=undefined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79572 --- Comment #8 from Richard Biener --- Btw, clang behaves the same: > clang++ t.C -O2 t.C:4:12: warning: reference cannot be bound to dereferenced null pointer in well-defined C++ code; pointer may be assumed to always convert to true [-Wundefined-bool-conversion] if () ~~ ^~~~ 1 warning generated. rguenther@e111:/tmp> ./a.out Segmentation fault (core dumped) and it doesn't diagnose *NULL either.
[Bug sanitizer/79572] [6/7 Regression] reference binding to null pointer not reported with -fsanitize=undefined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79572 --- Comment #7 from janus at gcc dot gnu.org --- (In reply to Markus Trippelsdorf from comment #2) > You can use -fno-delete-null-pointer-checks as a workaround for this issue. Thanks for the comment, that's very helpful. > But the C++ standard makes it very clear that references cannot be null, > otherwise you're invoking undefined behavior. Fully agree. I'm not trying to argue that GCC should adapt to cope with shitty code. But: There is a pretty dramatic change in behavior from version 5 to 6, in the sense that (bad) code that worked before suddenly stopped working. A warning is good, but I'd argue that in this case it's really not enough. So, yes, a runtime error would be the needed at least. I know that detecting such cases at compile time cannot be done in general, but for the case here, shouldn't it be possible to detect the dereferencing of a NULL pointer at compile time, simply by looking at this one line? f(*((int*) NULL));
[Bug sanitizer/79572] [6/7 Regression] reference binding to null pointer not reported with -fsanitize=undefined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79572 Marek Polacek changed: What|Removed |Added Status|NEW |ASSIGNED CC||mpolacek at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |mpolacek at gcc dot gnu.org --- Comment #6 from Marek Polacek --- Let me have a look.
[Bug sanitizer/79572] [6/7 Regression] reference binding to null pointer not reported with -fsanitize=undefined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79572 Markus Trippelsdorf changed: What|Removed |Added Status|RESOLVED|NEW CC||dodji at gcc dot gnu.org, ||dvyukov at gcc dot gnu.org, ||jakub at gcc dot gnu.org, ||kcc at gcc dot gnu.org Component|c++ |sanitizer Resolution|INVALID |--- Summary|[6/7 Regression] Segfault |[6/7 Regression] reference |with -O1 and higher on null |binding to null pointer not |reference |reported with ||-fsanitize=undefined --- Comment #5 from Markus Trippelsdorf --- This is an -fsanitize=undefined regression. 5.4.1 gives: runtime error: reference binding to null pointer of type 'const int 6 and trunk: No runtime error is reported.
