4 ms·

Author here. I firmly believe that people would choose superunsafecc because they don't know how much it will break their code. After all, it's not called "sup

Author here. I firmly believe that people would choose superunsafecc because they don't know how much it will break their code. After all, it's not called "superunsafecc," it's called "gcc" or "clang."

aidenn0 3y ago
> I firmly believe that people would choose superunsafecc because they don't know how much it will break their code. After all, it's not called "superunsafecc," it's called "gcc" or "clang." This might be true, but companies often spend a rather short amount of time selecting a compiler for their projects[1], and they won't switch in the middle of it. As long as "reasonable handling of UB" isn't a checkbox in anyone's product selection matrix, then it's not going to get selected. The current incentives are for compiler writers to ride the very edge of the standard becuase "X% faster" is something that everybody wants. I don't object to the thrust of your article, I just think you are putting everything on the compiler writers, when what compiler users actually use 90% of the time is The compiler that runs their favorite microbenchmark the fastest. The word "want" is complicated, so I used the term "revealed preference" in my first post, but it's not entirely wrong to say that by taking advantage of UB, compiler-writers are giving compiler users what they want; even if we both agree compiler-users want the wrong thing, and would want something different if they were more informed. As a side-note, I've explained the ISO aliasing rules to dozens of embedded programmers and they are always insistent that C allows free type punning because "C is just portable assembly." I show them -fno-strict-aliasing (or the equivalent for their compiler) and usually they move on, but about 10% of them want to file a bug against the compiler even after having it explained to them.

4 ms·

Author here. I firmly believe that people would choose superunsafecc because they don't know how much it will break their code. After all, it's not called "sup

by gavinhoward 3y ago

aidenn0 3y ago
> I firmly believe that people would choose superunsafecc because they don't know how much it will break their code. After all, it's not called "superunsafecc," it's called "gcc" or "clang." This might be true, but companies often spend a rather short amount of time selecting a compiler for their projects[1], and they won't switch in the middle of it. As long as "reasonable handling of UB" isn't a checkbox in anyone's product selection matrix, then it's not going to get selected. The current incentives are for compiler writers to ride the very edge of the standard becuase "X% faster" is something that everybody wants. I don't object to the thrust of your article, I just think you are putting everything on the compiler writers, when what compiler users actually use 90% of the time is The compiler that runs their favorite microbenchmark the fastest. The word "want" is complicated, so I used the term "revealed preference" in my first post, but it's not entirely wrong to say that by taking advantage of UB, compiler-writers are giving compiler users what they want; even if we both agree compiler-users want the wrong thing, and would want something different if they were more informed. As a side-note, I've explained the ISO aliasing rules to dozens of embedded programmers and they are always insistent that C allows free type punning because "C is just portable assembly." I show them -fno-strict-aliasing (or the equivalent for their compiler) and usually they move on, but about 10% of them want to file a bug against the compiler even after having it explained to them.