This is literally what __builtin_unreachable() does. But it has the added benefit of the compiler understanding the intent so it works well with diagnostics.
I could see an argument (similar to for assert()) to omit such a check in most production builds. Maybe you could enable it for a small amount of hosts, so that if it does happen with any frequency, somebody sees it somewhere.
But not every "unthinkable" case being reached represents a security problem as it does in this case. So in the general case of how to approach such assert-type checks, an abort might take down the process when not necessary, turning it into a DoS.
Edit: I am not sure if my friend the downvoter realizes I am not trying to justify legit security bugs, just talking abstractly about varying approaches to handling asserts for unforeseen or "allegedly impossible" circumstances.
I didn't downvote you and I interpreted your comment the way you said you meant it. I do happen to disagree, though.
For a project in a space that's notoriously vulnerability prone - I mean, when it was released it was competing with Sendmail - it seems very reasonably cautious to pepper the code with panic handlers in "impossible" places. They won't slow the code down any because they should never be evaluated, but give nice, noisy explosions when unexpected things happen. There's no downside to doing this.
If we could tell a priori which unreachable cases were reachable it wouldn't be such a problem.
Asserting only in debug builds is rather ineffective because the unthinkable input isn't in your testsuite. If it were, then it wouldn't have been unthinkable.
Right, but I am also suggesting another approach: if you have a large fleet of machines or a client app with a lot of usage, you can enable it in a small percentage of runs and if it hits in the wild you still have a chance of learning about it, without tearing down the process for all users. I have seen that strategy be effective.
Very hard to know which behavior is appropriate in advance though. An assert that turns out to represent a benign circumstance that is already handled, multiplied by large numbers of machines, can be pretty annoying.
Because it will never happen I guess. From my experience, it's because of this bad habbit of expecting the program to crash and provide a backtrace,the print is there for debugging. But you're right,it's not the sane way of doing it.
