https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89561
--- Comment #8 from bugsthecode at mail dot ru ---
(In reply to Martin Sebor from comment #7)
> 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.
>
Yes, it's a hard task to detect all undefined behaviour. It's less hard task to
generate sane code.
And main impact of -fsanitize, as far as I understand, is that it's a runtime
check. Of course runtime stuff can take a lot of performance. Like, try running
something under the valgrind. That's the performance hit of runtime debugging.
But issue lies in compile-time actions, since invalid code is generated at
compile time. There is a choice between fast compilation emiting miscompiled
stuff and proper compilation but maybe a bit slower. Does the speed of code
generation matter? Or should quality matter? Same questions apply to runtime:
should it run properly or just crash very fast?
> 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).
>
And what prohibits from emitting proper code in those cases? Dangling pointer,
you say? Ok, I take it. It may be unused dangling pointer. Still much better
than code executing arbitrary data located after the body of function, and even
dropping actual body of function like in bug 87515.
And how does returning nullptr instead of dangling pointer make generated code
faster? Unless the goal is to drop as much code as possible at all costs. In
that case I may propose to just generate any application like it was just 'void
main() {}'. That'd be fastest code ever.
> 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.
Well, it did take some effort to break compiler in these cases first (and other
cases as well probably), of course it'd take some effort to fix broken stuff
now.
