3 ms·
> If the compiler concludes that the program has no valid executions, then why not just generate an error message at compile time? I agree that that would be n
by tom_mellior 9y ago
> If the compiler concludes that the program has no valid executions, then why not just generate an error message at compile time?
I agree that that would be nice to see in this case, and it seems like this particular case would be low-hanging fruit, but it's not that simple. In particular, the compiler in this example most likely does not reason globally; it never actually decides that "the program has no valid executions". It does a series of local transformations, presumably based on facts of the form "if we can reach this point, then certain values are invalid".
Another thing about such error messages would be that they would push compilers more in the direction of verification tools, which they aren't, and cannot be.
Consider:
int f() {
return 1 / 0;
}
int g() {
int a = 0;
return 1 / a;
}
Clang warns about the first function, but not about the second one. If it warned about the second one, I could write a third function that always divided by zero, but that it could not warn about. If it learned to do that, I would find a fourth one, etc. This is an arms race that compilers cannot win, and they shouldn't try. You should use separate verification tools for that, which do the opposite of compiler warnings: They don't reject the program if it's trivially buggy, they reject it unless you prove that it is not buggy.
If compilers had more such warnings, programmers would be tempted to say "look, there is no warning, the code must be fine". That's the whole "if it compiles, it's correct" approach that gives some gullible people a false sense of security in other languages.
- mannykannot 9y agoI certainly hope that there are not many programmers thinking "if it compiles, it's correct" after having made their first logic error, though I realize some Haskell programmers make statements that are close to that. Clang and gcc will warn you about some of these issues if you give them the right flags (so much so that -Wall no longer means literally all warnings, IIRC), but then you run into static analysis' problem of burying you in false positives for conditional / data-dependent undefined behavior. I have found it instructive to play with Dafny, one of the languages where the compiler does require you to prove that a variety of bugs will not occur, but 'play' is the operative word here. It is not a feasible option for C. C has always been a language for (among other things) creating optimized code, but the implication of that has changed. Originally, it meant / required being 'close to the metal', but since then, effective automated optimization has come along, and the metal itself has become considerably more complicated (partly as a consequence of more capable optimization). As C programmers, we should understand that these changes have occurred, and what they mean for programming in C - or not use the optimizer.
- tome 9y ago> I certainly hope that there are not many programmers thinking "if it compiles, it's correct" after having made their first logic error, though I realize some Haskell programmers make statements that are close to that. No, the Haskell slogan is "If it compiles it works". "It works" is something quite different to "it is correct".
- peoplewindow 9y agoYou talk about compilers in the general case but UB causing pain like this is really a C and C++ phenomenon. Other compiled languages manage to have sane compilation strategies.
- tom_mellior 9y agoWhich of the points of my post is this in reference to?