Undefined behavior is not always identifiable through static analysis. Obviously it can be checked against at runtime, but that's actually quite expensive. It would, for example, include bounds checks for everything, and overflow checks on all signed arithmetic.

That's not the worst of it: the truly intractable part is preventing use-after-free UB. The only ways to do this are (a) remove malloc from your language; (b) add a lifetime system (incompatible with all existing C libraries); (c) add a garbage collector (which most projects written in C will not accept for performance reasons).

I think that's mostly solved by changing the whole of the idea from "remove/disallow all undefined behavior" to "remove as much of the common needed undefined behavior as possible such that most programs need not really use it". Perfect is the enemy of good.

That'd be fine if use-after-free was a corner case that doesn't show up often in practice, but every single exploit at Pwn2Own this year was UAF…

Are we arguing the same thing? If UAF is the cause of security problems, and UAF is undefined behavior now, redefining it under a special mode to mean "this is an error (whether or not the compiler enforces it)" at least clarifies the situation,and lets and included static analysis report an error as needed and capable.

That is, I'm not arguing that as much undefined behavior as possible should be made defined and possible, just that it's defined. That definition may very well be "you are not allowed to do this. Don't do this."

With portable software (as in, portability is more valuable than other factors), imperfect is the enemy. ;-)

We have over four decades history of portability being valued over correctness, stability and security. I'm not impressed with where it's gotten us.

See, I look at it as the opposite. You aren't really portable if your code isn't correct.

And once you've eliminated that, you have DoS bugs like forcing infinite loops, abandoned (referenced but unused) memory leaks, and worst-case hash table insertions. All of those are serious attacks for anything with a resource budget.

rlimit ftw

Trapping on an overflow register signal is very, very cheap, and there are standard libraries for it.

Some of this stuff can be caught at compile time. Like code that does signed addition of positive values and checks if they might be less.