3 ms·

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 program

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
      - layer8 3y ago
        Yes, you can fix it in some cases, but the real errors usually happen in complex code where it is much harder or impossible to detect at compile time. The examples in TFA are very simplified for exposition purposes, they are not representative of ease-of-detection.
  - weinzierl 3y ago
    I agree with you more than you think. "if the standards people started defining every possible instance of UB as a fatal error or as an implementation defined behavior," We can wish for that, but it does not and never will. Writing C or C++, first and foremost, means writing code against the standard and we have to deal with what the standard says. Of course we are free to give up on the standard and target a particular implementation of C or C++ in a particular compiler. If you also like to to call that writing C or C++ I would not argue with you. It is still a very different thing because you give up the primary advantage of C and C++ that you can compile basically everywhere. My point now is that if you give that up it makes no sense to stick with C or C++ in the first place and in this day and age.
    - dale_glass 3y ago
      > My point now is that if you give that up it makes no sense to stick with C or C++ in the first place and in this day and age. You wouldn't be giving anything up. The standard defining something as UB means you absolutely shouldn't be doing that. So a compiler doing something defined in case of UB can't harm you in any way, and doesn't deviate from the standard, because the standard prescribes no rules in the case you're invoking.
      - weinzierl 3y ago
        With giving up I meant giving up portability by targeting a particular implementation of C or C++ in a particular compiler. The standard is what it is and discussing a hypothetical standard is moot.
        dale_glass 3y ago
        You don't give up any portability. If the standard says that say, dereferencing a NULL pointer is UB it means you're not supposed to do that ever, on any OS or compiler. A compiler can choose to do something sensible like producing a fatal error message without any downside, since per standard that's not ever supposed to happen anyway.

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
    - layer8 3y ago
      Yes, you can fix it in some cases, but the real errors usually happen in complex code where it is much harder or impossible to detect at compile time. The examples in TFA are very simplified for exposition purposes, they are not representative of ease-of-detection.
- weinzierl 3y ago
  I agree with you more than you think. "if the standards people started defining every possible instance of UB as a fatal error or as an implementation defined behavior," We can wish for that, but it does not and never will. Writing C or C++, first and foremost, means writing code against the standard and we have to deal with what the standard says. Of course we are free to give up on the standard and target a particular implementation of C or C++ in a particular compiler. If you also like to to call that writing C or C++ I would not argue with you. It is still a very different thing because you give up the primary advantage of C and C++ that you can compile basically everywhere. My point now is that if you give that up it makes no sense to stick with C or C++ in the first place and in this day and age.
  - dale_glass 3y ago
    > My point now is that if you give that up it makes no sense to stick with C or C++ in the first place and in this day and age. You wouldn't be giving anything up. The standard defining something as UB means you absolutely shouldn't be doing that. So a compiler doing something defined in case of UB can't harm you in any way, and doesn't deviate from the standard, because the standard prescribes no rules in the case you're invoking.
    - weinzierl 3y ago
      With giving up I meant giving up portability by targeting a particular implementation of C or C++ in a particular compiler. The standard is what it is and discussing a hypothetical standard is moot.
      - dale_glass 3y ago
        You don't give up any portability. If the standard says that say, dereferencing a NULL pointer is UB it means you're not supposed to do that ever, on any OS or compiler. A compiler can choose to do something sensible like producing a fatal error message without any downside, since per standard that's not ever supposed to happen anyway.