5 ms·

I'm agreeing with the parent that the result is according to the spec. What I'm arguing is that we shouldn't call that a correct compilation. It is a wrong com

I'm agreeing with the parent that the result is according to the spec. What I'm arguing is that we shouldn't call that a correct compilation. It is a wrong compilation - is wrong with prior notice, and there is in fact no way to do it right, because the source is wrong (UB). I think I don't disagree about behavior, but about semantics. We shouldn't say, e.g. in a compiler's manual, that the compiler is free to (has the right to, is correct to) do anything when it encounters UB. Rather, I'd warn that the compilation might fail silenty on UB. The difference is not factual, it is in tone. Stating matter-of-factly that nasal demons is the correct result of compiling UB code is aggravating. It is the equivalent of the compiler singing nana-nana-na-na (or ätsch bätsch for the Germans).

tom_mellior 9y ago
> Rather, I'd warn that the compilation might fail silenty on UB. What do you mean by "fail"? Terminate compilation without producing output code? That's not possible, the compiler cannot detect all (or even most) UB at compilation time. Or do you mean it would produce "wrong" code (as it does now)? That's not what is commonly called "failure", and I think putting it that way is obscuring the issue, not making it clearer.
- peoplewindow 9y ago
  You're acting as if a compiler behaving reasonably is impossible. Yet Java compiles to code that runs basically as fast as C (modulo cases like where you use vectorised code in C and the JIT fails to auto-vectorise), but with rational and predictable behaviour in all cases. I suspect UB is going to seriously damage or largely kill off statically compiled languages in the long run. Speculating JIT compilers can compile code in such a way that all executions are defined yet which does not experience the speed penalty C programs suffer, because the optimiser is free to make risky assumptions that are checked on the fly and de-optimise if they fail. It's heavy to have a full blown compiler running at the same time as your app, but desktop/laptop machines tend to have spare cores doing nothing anyway, and on servers the compiler is only running for a short period during warmup anyway and then is hardly used again.
  - tom_mellior 9y ago
    You can get pretty good safety-performance trade-offs even without JITting, but yes, JITs are also great. But all that is only true for languages that are less insane than C, I agree. (Come to think of it, I don't know if people have explored the field of UBSan-style things in combination with JIT technologies.) As for a "reasonable" C compiler, there is always -O0.
    - peoplewindow 9y ago
      They are being explored now, check out this paper on lenient C, which works by JIT compiling LLVM on top of the JVM: http://webcache.googleusercontent.com/search?q=cache%3Assw.jku.at%2FGeneral%2FStaff%2FManuelRigger%2FManLang17.pdf&oq=cache%3Assw.jku.at%2FGeneral%2FStaff%2FManuelRigger%2FManLang17.pdf&aqs=chrome..69i57j69i58.976j0j4&sourceid=chrome&ie=UTF-8 http://webcache.googleusercontent.com/search?q=cache%3Assw.j...
      - tom_mellior 9y ago
        Ah, yes, thanks. In fact, their work on Safe Sulong was more along the lines of what I was thinking of, but this is also interesting.

tom_mellior 9y ago

> Rather, I'd warn that the compilation might fail silenty on UB. What do you mean by "fail"? Terminate compilation without producing output code? That's not possible, the compiler cannot detect all (or even most) UB at compilation time. Or do you mean it would produce "wrong" code (as it does now)? That's not what is commonly called "failure", and I think putting it that way is obscuring the issue, not making it clearer.

peoplewindow 9y ago
You're acting as if a compiler behaving reasonably is impossible. Yet Java compiles to code that runs basically as fast as C (modulo cases like where you use vectorised code in C and the JIT fails to auto-vectorise), but with rational and predictable behaviour in all cases. I suspect UB is going to seriously damage or largely kill off statically compiled languages in the long run. Speculating JIT compilers can compile code in such a way that all executions are defined yet which does not experience the speed penalty C programs suffer, because the optimiser is free to make risky assumptions that are checked on the fly and de-optimise if they fail. It's heavy to have a full blown compiler running at the same time as your app, but desktop/laptop machines tend to have spare cores doing nothing anyway, and on servers the compiler is only running for a short period during warmup anyway and then is hardly used again.
- tom_mellior 9y ago
  You can get pretty good safety-performance trade-offs even without JITting, but yes, JITs are also great. But all that is only true for languages that are less insane than C, I agree. (Come to think of it, I don't know if people have explored the field of UBSan-style things in combination with JIT technologies.) As for a "reasonable" C compiler, there is always -O0.
  - peoplewindow 9y ago
    They are being explored now, check out this paper on lenient C, which works by JIT compiling LLVM on top of the JVM: http://webcache.googleusercontent.com/search?q=cache%3Assw.jku.at%2FGeneral%2FStaff%2FManuelRigger%2FManLang17.pdf&oq=cache%3Assw.jku.at%2FGeneral%2FStaff%2FManuelRigger%2FManLang17.pdf&aqs=chrome..69i57j69i58.976j0j4&sourceid=chrome&ie=UTF-8 http://webcache.googleusercontent.com/search?q=cache%3Assw.j...
    - tom_mellior 9y ago
      Ah, yes, thanks. In fact, their work on Safe Sulong was more along the lines of what I was thinking of, but this is also interesting.