> the behavior of the program is implementation-defined
You're basically defining undefined behavior. The way to do this "properly" would be "the program is allowed to do x, y, z, or also trap"–there's really not much else you can do.
Well, it is not that easy. Specifying a subset of allowed outcomes might still prevent future evolution.
For example bound checking, while fairly cheap for serial code, makes it very hard to vectorize code effectively. Then again so does IEEE FP math and that's why we have -ffast-math...
In the end, it is not impossible, it is just tradeoffs.
I'm generally on the opinion that there should be as little UB as possible, but probably this is better done by compilers that can push the limit of static and dynamic checking technology instead of the standard mandating it.
Right, that’s my point at the top of the thread :) I’m just saying if you don’t end up with something that looks like what I just mentioned you’re really not specifying anything, so you might as well go for undefined behavior. This is fine.
You're basically defining undefined behavior. The way to do this "properly" would be "the program is allowed to do x, y, z, or also trap"–there's really not much else you can do.