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.