https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89561
--- Comment #7 from Martin Sebor <msebor at gcc dot gnu.org> ---
It's not possible to detect all instances of undefined behavior and emit some
"reasonable" or "safe" code (whatever that might mean in each instance),
certainly not without compromising efficiency. Timing a program compiled with
the -fsanitize= options shows just how much of an impact even a subset of such
detection has.
On the other hand, it certainly is possible to provide options to control what
sort of code GCC should emit in addition to giving a warning when it does
detect such undefined behavior. In response to pr89218, I don't think it's
unreasonable to ask for an option to make GCC emit the same code as if the
function returned zero (since GCC issues a warning, what the default setting of
the option should be can be debated). GCC does that in other contexts. For
example, in:
const char* const a[] = { "1", "12", "123" };
const char* f (void) { return a[99]; }
GCC replaces the argument of the return statement with zero, unfortunately
without a warning). Or in
void *f (void) { int i; return &i; }
GCC has f() return null rather than a dangling pointer, in addition to issuing
a warning.
At the same time, in
const char a[][4] = { "1", "12", "123" };
const char* f (void) { return a[99]; }
GCC emits code returning an invalid address (but it does issue a warning).
The trouble here, from my point of view, is more than just the lack of
consistency, but the lack of consensus on how to respond to such instances, or
if an effort should even be made to deal with these cases.
