On Thu, Oct 04, 2018 at 03:19:56PM -0600, Jeff Law wrote: > On 10/4/18 1:39 PM, Josef Wolf wrote: > > When gcc inserts trap instructions, it assumes that there is some sort of > > hanlder installed for this? How should such a handler look like? I'd rather > > have the handler output some useful diagnostics instead of just crashing. > It's up to the application to figure out how to handle this situation. > > The compiler only inserts the traps when it can prove conclusively that > the program will trigger undefined behavior at a particular execution point. I think it's the other way around: the trap is inserted when gcc sees a chance for NULL-dereference. > Stopping the program immediately is far better than the compiler trying > to issue diagnostics or anything like that. I'd very much prefer a warning at compile time! With a warning, I'd have a chance to fix the problem before the trap is taken in production. I fail to see any good in this trap: - If the compiler can detect such a serious problem, then it should emit a warning AT COMPILE TIME. - If the compiler inserts a trap, then this trap should improve the situation instead of making it worse. Simply crashing leaves you without any clue. You have no idea where to look for the bug. The crash could even be by a power outage. That's not exactly improving the situation. Issuing a diagnostic "Oops, NULL-dereference at adsf.c:123" would improve the situation: you know where to look for the fix. > You're in the world of > undefined behavior, the safe thing to do is halt immediately. Whether stopping immediately is good or not depends very much on the context. Instead of stopping immediately, I'd also prefer to get something like "hey NULL-dereference at foobar.c:123. Stopping now." > That indicates a deeper problem (the existence of the call changing the > paths through the program. The existence of a call to a function with potential side effets (e.g. printf) can AND WILL very much change paths due to the fact that the optimizer needs to drop some assumptions. > I'll repeat, if the compiler is inserting traps, the program is horribly > buggy at those points. You should dig into why. If this would be true, then traps in a program that is guaranteed to never dereferencing NULL would be an indication of bugs in the compiler? -- Josef Wolf jw@xxxxxxxxxxxxx
