A good compiler might define its behavior. Just because the spec leaves things undefined doesn't mean the compiler should.
Arguably a JS VM written in C++ may be vulnerable until the compiler is proven not to be.
Arguably a JS VM written in C++ may be vulnerable until the compiler is proven not to be.
All indications are that it's not possible to eliminate undefined behavior from C and C++ without significantly regressing performance.
> Arguably a JS VM written in C++ may be vulnerable until the compiler is proven not to be.
Vulnerabilities in JS engines are enormously more likely to be the result of undefined behavior in C++ than the result of C++ compiler miscompilations. As I said, eliminating miscompilations in LLVM/clang does nothing to address the problems of C++ UB.
If you make the specific way the compiler handles certain cases of UB part of the spec (e.g. overflow wraps around, who cares about sign-magnitude anyway?), then programmers using that compiler can rely on these specifics to write code that does something sensible even when UB is invoked.
My point is that you can write your compiler spec to make explicit how exactly various kinds of UB are actually implemented, which then allows you to program to that spec and know that e.g. your overflowing bounds check is not completely eliminated from the program, but instead compiled into the machine instructions you had in mind.
If a compiler is verified to conform to such a specification, unintended changes in handling UB will be very obvious, since the spec will have to be changed to make the verification go through.
Yes, it does, because some optimizations now become invalid. For example, a compiler would no longer allowed to delete a provably out-of-bounds write. This happens all the time.
I don't think there's a lot of practical value in changing the definition of some kinds of undefined behavior to "memory corruption" (however defined) in the first place.