4 ms·

This attitude drives me crazy. C was once a simple language, but now the only people that can write it "correctly" are compiler implementers, and if they fuck u

This attitude drives me crazy. C was once a simple language, but now the only people that can write it "correctly" are compiler implementers, and if they fuck up your code, it's your fault. You know how Linus will practically murder anyone that breaks user space, even if user space is "wrong"? I wish compiler makers had the same ethos. BTW, go look at how many optimizations are explicitly disabled to compile the kernel without it breaking and then come back to me with how these are a good idea. One of the most critical pieces of software infrastructure in the world looks at how broken compilers are and says yeah, leave that junk out.

josephcsible 5y ago
What you want would basically prohibit all optimizations.
- overgard 5y ago
  Your point is the standard that "optimizations shouldn't fuck up working code" is unreasonable? What point is there to optimizing something thats wrong? So you can break things 10% faster?
  - josephcsible 5y ago
    > Your point is the standard that "optimizations shouldn't fuck up working code" is unreasonable? By "working code", do you mean code that the standard and/or target implementation promise will do what you want, or do you mean code that just happened to do what you want the last time you tested it on your system? If you mean the latter, then yes.
    - overgard 5y ago
      What percentage of code do you honestly think has no undefined behavior? (hint: hardly any). Are you fortunate enough to work in one of those code bases? Remember its not up to you to not write UB, its up to everyone that touches the code base. If you are stuck with UB, would you prefer a compiler that does the safe thing, or a compiler that unleashes dragons?
      - josephcsible 5y ago
        > What percentage of code do you honestly think has no undefined behavior? (hint: hardly any). Are you fortunate enough to work in one of those code bases? Remember its not up to you to not write UB, its up to everyone that touches the code base. Maybe we should focus on better warnings, static analyzers, and UBSan, so that people with UB can fix their code, rather than not letting compilers optimize anymore. > If you are stuck with UB, would you prefer a compiler that does the safe thing, or a compiler that unleashes dragons? I'd very much prefer that my compiler unleashes dragons, so that I notice the bugs and can fix them. If my compiler did what you want, then when someone else compiled my code with a different compiler, they'd find them instead. (And it's obviously totally unrealistic to expect that literally every compiler in the world would do what you're asking.)
- unnah 5y ago
  There are plenty of optimizations in Linux, they just pick ones that don't break userspace. Similarly compiler writers could do optimizations without breaking user programs. Although I guess testing compiler backward compatibility would probably be more difficult than kernel backward compatibility, since compilers present a larger interface (multiple entire programming languages).
  - UncleMeat 5y ago
    > Similarly compiler writers could do optimizations without breaking user programs. This isn't possible, since "breaking user programs" in this context means "violating the intuition of the programmer", who is an unknown person who has never written their intuition down to be observed by the compiler authors. If you are actually talking about breaking user programs, both C and C++ already have ABI stability as a design goal, which hugely limits changes to the languages but enables people to keep linking against binaries that were compiled ages ago.
    - unnah 5y ago
      GCC and clang developers already do regularly compile and test a limited number of open source packages, and investigate any newly occurring failures. For now they ignore failures if the code does not conform to standards (except for notifying upstream developers). In principle, in such cases they could expend effort to find similar (possibly simpler) optimizations that do not change the existing behavior of the code. Alternatively, they could disable the relevant optimizations at -O2 (and maybe -O3) level. I believe MSVC developers do put more effort than GCC/Clang developers to maintain source-level backwards compatibility. Alternative development strategies are certainly possible, but I understand that the GCC/Clang developers do face pressure from a significant subset of users to maximize performance at any cost.
      - josephcsible 5y ago
        > In principle, in such cases they could expend effort to find similar (possibly simpler) optimizations that do not change the existing behavior of the code. This wouldn't just be expending effort. It would be making all code GCC/Clang ever compiled be slower. > Alternatively, they could disable the relevant optimizations at -O2 (and maybe -O3) level. Ditto.

josephcsible 5y ago

What you want would basically prohibit all optimizations.

overgard 5y ago
Your point is the standard that "optimizations shouldn't fuck up working code" is unreasonable? What point is there to optimizing something thats wrong? So you can break things 10% faster?
- josephcsible 5y ago
  > Your point is the standard that "optimizations shouldn't fuck up working code" is unreasonable? By "working code", do you mean code that the standard and/or target implementation promise will do what you want, or do you mean code that just happened to do what you want the last time you tested it on your system? If you mean the latter, then yes.
  - overgard 5y ago
    What percentage of code do you honestly think has no undefined behavior? (hint: hardly any). Are you fortunate enough to work in one of those code bases? Remember its not up to you to not write UB, its up to everyone that touches the code base. If you are stuck with UB, would you prefer a compiler that does the safe thing, or a compiler that unleashes dragons?
    - josephcsible 5y ago
      > What percentage of code do you honestly think has no undefined behavior? (hint: hardly any). Are you fortunate enough to work in one of those code bases? Remember its not up to you to not write UB, its up to everyone that touches the code base. Maybe we should focus on better warnings, static analyzers, and UBSan, so that people with UB can fix their code, rather than not letting compilers optimize anymore. > If you are stuck with UB, would you prefer a compiler that does the safe thing, or a compiler that unleashes dragons? I'd very much prefer that my compiler unleashes dragons, so that I notice the bugs and can fix them. If my compiler did what you want, then when someone else compiled my code with a different compiler, they'd find them instead. (And it's obviously totally unrealistic to expect that literally every compiler in the world would do what you're asking.)
unnah 5y ago
There are plenty of optimizations in Linux, they just pick ones that don't break userspace. Similarly compiler writers could do optimizations without breaking user programs. Although I guess testing compiler backward compatibility would probably be more difficult than kernel backward compatibility, since compilers present a larger interface (multiple entire programming languages).
- UncleMeat 5y ago
  > Similarly compiler writers could do optimizations without breaking user programs. This isn't possible, since "breaking user programs" in this context means "violating the intuition of the programmer", who is an unknown person who has never written their intuition down to be observed by the compiler authors. If you are actually talking about breaking user programs, both C and C++ already have ABI stability as a design goal, which hugely limits changes to the languages but enables people to keep linking against binaries that were compiled ages ago.
  - unnah 5y ago
    GCC and clang developers already do regularly compile and test a limited number of open source packages, and investigate any newly occurring failures. For now they ignore failures if the code does not conform to standards (except for notifying upstream developers). In principle, in such cases they could expend effort to find similar (possibly simpler) optimizations that do not change the existing behavior of the code. Alternatively, they could disable the relevant optimizations at -O2 (and maybe -O3) level. I believe MSVC developers do put more effort than GCC/Clang developers to maintain source-level backwards compatibility. Alternative development strategies are certainly possible, but I understand that the GCC/Clang developers do face pressure from a significant subset of users to maximize performance at any cost.
    - josephcsible 5y ago
      > In principle, in such cases they could expend effort to find similar (possibly simpler) optimizations that do not change the existing behavior of the code. This wouldn't just be expending effort. It would be making all code GCC/Clang ever compiled be slower. > Alternatively, they could disable the relevant optimizations at -O2 (and maybe -O3) level. Ditto.