5 ms·

The issue of UB has everything to do with how compilers implement it. If people are having problems, they should complain to compiler writers. They always have

The issue of UB has everything to do with how compilers implement it. If people are having problems, they should complain to compiler writers. They always have the option of creating slower code that checks for obvious problems like initialized variables. However, if a company/project writes a compiler that is a little slower than the competitor, people with almost always complain that it is a bad compiler. So the result is what you have nowadays: they're always looking for every small opportunity to generate faster code at the expense of safety.

weinzierl 3y ago
"[..] 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.
        3y ago
Thiez 3y ago
Why complain to the compiler writers? As you say, people want the fastest compilers for their language, so compilers will prioritize that over other concerns. Users may rant and complain, but they won't use a slower compiler. If you really want less UB, switch to a different language or change the language! Complain to the standards committee, have them define behavior that is currently undefined, or impose restrictions on allowable behaviors. Compilers are always going to optimize to the extent that the language standard allows, so change the standard.
pyrolistical 3y ago
> However, if a company/project writes a compiler that is a little slower than the competitor, people with almost always complain that it is a bad compiler. That is bullshit. There are plenty of project that would gladly trade performance for more correctness. I would go as far to say most projects would make that choice if articles like this get mindshare. “It’s mostly as fast as clang but errors upon UB” is an easy sell

weinzierl 3y ago

"[..] 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.
        3y ago

Thiez 3y ago

Why complain to the compiler writers? As you say, people want the fastest compilers for their language, so compilers will prioritize that over other concerns. Users may rant and complain, but they won't use a slower compiler. If you really want less UB, switch to a different language or change the language! Complain to the standards committee, have them define behavior that is currently undefined, or impose restrictions on allowable behaviors. Compilers are always going to optimize to the extent that the language standard allows, so change the standard.

pyrolistical 3y ago

> However, if a company/project writes a compiler that is a little slower than the competitor, people with almost always complain that it is a bad compiler. That is bullshit. There are plenty of project that would gladly trade performance for more correctness. I would go as far to say most projects would make that choice if articles like this get mindshare. “It’s mostly as fast as clang but errors upon UB” is an easy sell