I believe it to be the case that any optimization in conjunction with a non-conforming program can lead to a subtle or hard-to-understand bug, including giving

I believe it to be the case that any optimization in conjunction with a non-conforming program can lead to a subtle or hard-to-understand bug, including giving literally the wrong answer. So what is the solution? Disallow optimization, or go to hellish lengths to write a hard-to-follow spec that only permits optimizations that do not surprise people? On the other hand, it is not hard for me to incorporate into my mental model of a language that a program should eventually "do something" and if it doesn't, it is literally a wrong program. In fact, that's exactly what I thought when I saw the code in question. Before even realizing what it is about: I read it like a normal program, I saw that it can only ever return true, therefore that code can do only one thing, and all that fluff in there does not impact the end result. So I don't think it's particularly non-obvious, but it does require something from the reader. I'm ok with that, there's a lot in C and C++ you can't just assume. I call this a "weird program." It's trying to brute-force an answer out of the computer, but it's the kind of an answer that may or may not ever come. Hardly unlike a program that tries to answer the halting problem. Not necessarily an illegitimate program (bruteforcing is a legitimate way to find answers), but not the kind of thing you'd put inside a normal application. So I'm not concerned about normal applications running into this issue much. If a normal application could go into an infinite do-nothing loop, that is almost definitely a bug -- a literally wrong program. The optimization here only changes how that wrongness manifests, which is expected for UB & optimizations. I do like that C gives you the escape hatch of using a constant controlling expression if you really want a true "potentially-infinite" loop.