4 ms·

"[..] this International Standard imposes no requirements on the behavior of programs that contain undefined behavior. " What you describe fits for "implementa

"[..] this International Standard imposes no requirements on the behavior of programs that contain undefined behavior. " What you describe fits for "implementation defined behavior". If you want to write code that works with different compilers, a single compiler with every UB defined, gains you nothing. If you don't need that flexibility, you can just use a language without UB in the first place.

dale_glass 3y ago
You do. Take the EraseAll example Ideally it's a compile time error. Less ideally it jumps to a NULL pointer and immediately crashes. Either means the programmer must fix the code, which also stops being a problem on other compilers.
- weinzierl 3y ago
  "Ideally it's a compile time error." I agree with that, but the standard does not agree with both of us. My point is that choosing C or C++ makes sense if you see an advantage in programming against an ubiquitous and almost universal standard. If you have the freedom to implement against a particular compiler implementation there is no good argument to not also taking the freedom to choose a different language altogether. I know in the real world this is not so easy. I worked in automotive with their certified C compilers long enough and I wouldn't have had the choice to select another language. Doesn't mean everyone wouldn't have been better off with a language without UB in the first place and I think we are getting there.
  - dale_glass 3y ago
    Nonsense. The standard literally doesn't bind us in any way whatsoever. UB means there are no rules, anything goes. If the compiler is free to make demons fly out of my nose, it's equally free to produce a nice error message to the effect of "Don't do that". I'd much prefer if the standards people started defining every possible instance of UB as a fatal error or as an implementation defined behavior, but that's not strictly required.
    - layer8 3y ago
      Some instances of UB are data-dependent, and some would require solving the halting problem to statically distinguish them from non-UB. What you propose is therefore not generally possible at compile time, and at runtime only with considerable performance impact.
      - weinzierl 3y ago
        Thanks for pointing that out. Detecting UB is hard and sometimes impossible in C and C++. If you design your language accordingly you can avoid that. At least I think that is how Rust deals with it, but I'm happy to be convinced otherwise.
        coliveira 3y ago
        If some form of UB is impossible to detect, then the compiler cannot do anything about it either, making the whole debate useless. Any action taken by a compiler relating to UB must be for some cause that is detectable at compilation time.
        layer8 3y ago
        That’s not quite true, the compiler could add code to detect all UB at runtime, and then abort or whatever. It’s just that this would also pessimize UB-free code, and most compilers opt to not do that, at least in release mode.
        weinzierl 3y ago
        That is not true and very important to understand. The optimizations a compiler does by eliding UB stuff are often very effective and I think no one in the thread has questioned that. It is a fallacy, though, to think that these optimizations could be replaced by diagnostics. That would be hard in most cases and sometimes impossible.
      - dale_glass 3y ago
        So fix it to the extent possible. Eg, this: https://t.co/Z1Ib2fIyu6 https://t.co/Z1Ib2fIyu6 Is easily fixable. A. static Function Do; -- This is a syntax error, initialization is mandatory. B. It's initialized to nullptr, and compiled to jmp 0x0

dale_glass 3y ago

You do. Take the EraseAll example Ideally it's a compile time error. Less ideally it jumps to a NULL pointer and immediately crashes. Either means the programmer must fix the code, which also stops being a problem on other compilers.

weinzierl 3y ago
"Ideally it's a compile time error." I agree with that, but the standard does not agree with both of us. My point is that choosing C or C++ makes sense if you see an advantage in programming against an ubiquitous and almost universal standard. If you have the freedom to implement against a particular compiler implementation there is no good argument to not also taking the freedom to choose a different language altogether. I know in the real world this is not so easy. I worked in automotive with their certified C compilers long enough and I wouldn't have had the choice to select another language. Doesn't mean everyone wouldn't have been better off with a language without UB in the first place and I think we are getting there.
- dale_glass 3y ago
  Nonsense. The standard literally doesn't bind us in any way whatsoever. UB means there are no rules, anything goes. If the compiler is free to make demons fly out of my nose, it's equally free to produce a nice error message to the effect of "Don't do that". I'd much prefer if the standards people started defining every possible instance of UB as a fatal error or as an implementation defined behavior, but that's not strictly required.
  - layer8 3y ago
    Some instances of UB are data-dependent, and some would require solving the halting problem to statically distinguish them from non-UB. What you propose is therefore not generally possible at compile time, and at runtime only with considerable performance impact.
    - weinzierl 3y ago
      Thanks for pointing that out. Detecting UB is hard and sometimes impossible in C and C++. If you design your language accordingly you can avoid that. At least I think that is how Rust deals with it, but I'm happy to be convinced otherwise.
      - coliveira 3y ago
        If some form of UB is impossible to detect, then the compiler cannot do anything about it either, making the whole debate useless. Any action taken by a compiler relating to UB must be for some cause that is detectable at compilation time.
        layer8 3y ago
        That’s not quite true, the compiler could add code to detect all UB at runtime, and then abort or whatever. It’s just that this would also pessimize UB-free code, and most compilers opt to not do that, at least in release mode.
        weinzierl 3y ago
        That is not true and very important to understand. The optimizations a compiler does by eliding UB stuff are often very effective and I think no one in the thread has questioned that. It is a fallacy, though, to think that these optimizations could be replaced by diagnostics. That would be hard in most cases and sometimes impossible.
    - dale_glass 3y ago
      So fix it to the extent possible. Eg, this: https://t.co/Z1Ib2fIyu6 https://t.co/Z1Ib2fIyu6 Is easily fixable. A. static Function Do; -- This is a syntax error, initialization is mandatory. B. It's initialized to nullptr, and compiled to jmp 0x0