Robert Dewar wrote on : > One thing to realize in this discussion is that it is not > possible in general to warn when a programmer is depending > on undefined behavior, since by definition you cannot in > general guess what misunderstandings the programmer has > about C, and hence what behavior is expected. > > There are some cases where you can guess well enough that > you can provide warnings that won't have an excessive > number of annoying false positivesm, and warnings in > such cases are appropriate. > > But some contributions to this thread have seemed to > come near to a position of requiring warnings whenever > the compiler does something that might violate expectations > of a programmer writing undefined C code, and as a general > principle this is fundamentally impossible.
And some have been pleas for the compiler to DWIM. Which, while it would be nice, is not just impossible, but conceptually flawed to the point of meaninglessness because it begs the question. This is because whatever the compiler assumes you /actually/ meant when it's trying to DWYM would have to be based on a set of rules/heuristics/inferences that would be just as liable as the current optimisation vs. undefined behaviour rules to misunderstandings that end up introducing security violations - but with the added disadvantage of not being in accord with a well-defined standard of behaviour, but being some ad-hoc and unpredictable set of transformations that you can't even know to avoid. In short, any attempt by the compiler to DWIM would just move the same class of problem around, but make it harder to detect; a lose-lose situation for everyone. At least with a clear standard, it's possible to make guarantees about when and whether a program is correct or not. cheers, DaveK -- Can't think of a witty .sigline today....