3 ms·

Different people have different ideas on what "makes sense". The point of a standard is to not have to use common sense, which is usually not common al all. So

Different people have different ideas on what "makes sense". The point of a standard is to not have to use common sense, which is usually not common al all. So there is no point is saying that when the standard does not say anything you should use common sense. If the standard says nothing, you should just avoid relying of that thing. The compiler is not responsible for the quality of the source code. The programmer is. The compiler is responsible for the quality of the machine code, assuming that the source code is correct. It is good to have tools to check the quality of source code, but they are a different thing from compilers. Personally, I am happy that the compiler optimizes the code for me when I write correct C/C++ programs. If I make a mistake and inadvertently do UB, I take the responsibility, without shifting it on the innocent compiler.

pjmlp 7y ago
> The compiler is not responsible for the quality of the source code. The programmer is. The last 40 years have proven how well it works in practice, specially if one plugs some kind of networking into it. Taking the responsibility should be taken to the same liability level of other engineering disciplines, then it would be interesting to see how long the myth of only bad programmers write bad C will survive.
- comex 7y ago
  I don't know how much this actually affects your argument, since you seem to be making a more general statement, but for the record: it's extraordinarily rare for vulnerabilities to be caused by compiler optimizations specifically. I've heard of a few instances (BIND denial of service; Linux TUN bug becoming exploitable instead of a denial of service; IIRC something with Native Client), but they're interesting precisely because they're rare. So I'd say that one shouldn't oppose compiler optimizations directly because of the risk of security vulnerabilities, although of course the prevalence of vulnerabilities can still be evidence that C programmers are prone to mistakes in general.

pjmlp 7y ago

> The compiler is not responsible for the quality of the source code. The programmer is. The last 40 years have proven how well it works in practice, specially if one plugs some kind of networking into it. Taking the responsibility should be taken to the same liability level of other engineering disciplines, then it would be interesting to see how long the myth of only bad programmers write bad C will survive.

comex 7y ago
I don't know how much this actually affects your argument, since you seem to be making a more general statement, but for the record: it's extraordinarily rare for vulnerabilities to be caused by compiler optimizations specifically. I've heard of a few instances (BIND denial of service; Linux TUN bug becoming exploitable instead of a denial of service; IIRC something with Native Client), but they're interesting precisely because they're rare. So I'd say that one shouldn't oppose compiler optimizations directly because of the risk of security vulnerabilities, although of course the prevalence of vulnerabilities can still be evidence that C programmers are prone to mistakes in general.