Once again, you focus solely on performance. This is why I don't believe you care about correctness. But to answer your question, because the malicious compile

Once again, you focus solely on performance. This is why I don't believe you care about correctness. But to answer your question, because the malicious compiler doubled the work I had to go to get to this point. Or worse. Maybe it increased the work by an order of magnitude. In addition, the checks are what prevent UB, especially the kind where you claim that any pointer anywhere can mess up everything. It's not UB if the behavior is defined as a crash before anything bad happens. And to answer your complaint that I'm leaving performance on the table, so what? Sure, I'm "messing" with speculation (though not by much because I tell the compiler that the error branch is unlikely to be taken), but Spectre and Meltdown showed that maybe speculation was a bad thing. By the way, in my bc, I actually turn a lot of checks off, the checks for which I am 10 9's sure there aren't problems. Not an exaggeration, by the way; I've run my bc under a fuzzer for probably 50 billion executions or more. And every single one of the paths were fixed until they came out clean in the sanitizers and Valgrind. Even across the entire world, I doubt my bc has run 50 billion unique executions; most of the time, people run it on the same scripts with similar data, over and over. In my other project, I don't turn off checks because it hasn't seen that level of testing. That's why I said you could attack bc; checks will actually be off. Make sure you do it in release mode, though if you get an assert to trigger in debug mode first, that same input should also cause UB in release mode. Have fun. I'm done. Contact my through my bio if you succeed.