3 ms·

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

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
      To not giving up portability all compilers would have to do what you propose. They won't as long as the standard doesn't mandate it. So we are back at the point where we agree that the standard contains some unfortunate things. Now, standard conformant compilers do exactly what you propose, they are just not C or C++ compilers and the standard is not the C or C++ standard.
      - dale_glass 3y ago
        > To not giving up portability all compilers would have to do what you propose. Not in a lot of cases. Eg, let's suppose that GCC defines a NULL pointer dereference to act exactly like a normal one. That is, the compiler dereferences the pointer, and whatever the CPU/OS says is going to happen when you read from 0x0, happens. Meanwhile, Clang continues with behaviors that can say lead to a function being entirely replaced with "return true". There's no problem whatsoever with this. You're still not supposed to dereference null pointers. It's just that on GCC in particular you get a predictable error. And being an error you can't really rely on it -- your program still crashes and crashes are still undesirable, and therefore you will fix whatever leads to that outcome. And on Clang maybe you don't crash but the program doesn't do what you expect it to, which is still a bug to be fixed. You have a bug in both versions which manifests in different ways (but that is fine, because UB says anything goes so there's no requirement whatsoever for both compilers to have the program break identically), but it's the same bug that needs the same fix. After the bug fix, your GCC compiled version doesn't crash and runs correctly, and your Clang compiled version doesn't crash and runs correctly. The behavior in the end is identical.
    - Kamq 3y ago
      > 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. Says who? The standard doesn't say that. At most it says that if you're trying to write portable C, you shouldn't do that. But not everyone is trying to write something portable.
      - dale_glass 3y ago
coliveira 3y ago
> Writing C or C++, first and foremost, means writing code against the standard This was never true and never will be. There are tons of C and C++ code that cannot be compiled in more than a few compilers. The standard is the minimum denominator, but all compilers have something beyond the standard that is used in practice. Just check the Linux code, for example. > if you give that up it makes no sense to stick with C or C++ No, the whole point of UB is that every compiler can do what it wants in that situation. C/C++ actively embrace differences between compilers, while trying to standardize the core meaning of the language.
- weinzierl 3y ago
  Linux is an excellent example. There has been a fork that made it compile with the Intel compiler and if I remember correctly it was moderately faster. Of course it went nowhere. Writing standard conformant code is hard and you do it if you have a good reason to do it. A lot of software has. The Linux kernal hasn't and that is fine. If your project also doesn't have that constraint, good for you. 30 years ago you would still choose C and a particular compiler and you could get things done. Nowadays, why bother? You could choose a language that has no UB, compiles on any hardware that is reasonably common and is still performant.

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
    To not giving up portability all compilers would have to do what you propose. They won't as long as the standard doesn't mandate it. So we are back at the point where we agree that the standard contains some unfortunate things. Now, standard conformant compilers do exactly what you propose, they are just not C or C++ compilers and the standard is not the C or C++ standard.
    - dale_glass 3y ago
      > To not giving up portability all compilers would have to do what you propose. Not in a lot of cases. Eg, let's suppose that GCC defines a NULL pointer dereference to act exactly like a normal one. That is, the compiler dereferences the pointer, and whatever the CPU/OS says is going to happen when you read from 0x0, happens. Meanwhile, Clang continues with behaviors that can say lead to a function being entirely replaced with "return true". There's no problem whatsoever with this. You're still not supposed to dereference null pointers. It's just that on GCC in particular you get a predictable error. And being an error you can't really rely on it -- your program still crashes and crashes are still undesirable, and therefore you will fix whatever leads to that outcome. And on Clang maybe you don't crash but the program doesn't do what you expect it to, which is still a bug to be fixed. You have a bug in both versions which manifests in different ways (but that is fine, because UB says anything goes so there's no requirement whatsoever for both compilers to have the program break identically), but it's the same bug that needs the same fix. After the bug fix, your GCC compiled version doesn't crash and runs correctly, and your Clang compiled version doesn't crash and runs correctly. The behavior in the end is identical.
  - Kamq 3y ago
    > 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. Says who? The standard doesn't say that. At most it says that if you're trying to write portable C, you shouldn't do that. But not everyone is trying to write something portable.
    - dale_glass 3y ago

coliveira 3y ago

> Writing C or C++, first and foremost, means writing code against the standard This was never true and never will be. There are tons of C and C++ code that cannot be compiled in more than a few compilers. The standard is the minimum denominator, but all compilers have something beyond the standard that is used in practice. Just check the Linux code, for example. > if you give that up it makes no sense to stick with C or C++ No, the whole point of UB is that every compiler can do what it wants in that situation. C/C++ actively embrace differences between compilers, while trying to standardize the core meaning of the language.

weinzierl 3y ago
Linux is an excellent example. There has been a fork that made it compile with the Intel compiler and if I remember correctly it was moderately faster. Of course it went nowhere. Writing standard conformant code is hard and you do it if you have a good reason to do it. A lot of software has. The Linux kernal hasn't and that is fine. If your project also doesn't have that constraint, good for you. 30 years ago you would still choose C and a particular compiler and you could get things done. Nowadays, why bother? You could choose a language that has no UB, compiles on any hardware that is reasonably common and is still performant.