On Fri, 25 Mar 2016 06:54 am, BartC wrote: >> In the case of C, the line is limited to working with some specific type >> (say, an int32). Even there, if the addition might overflow, the >> behaviour is undefined and the compiler can do anything it wants >> (including time travel, > > I'm pretty sure it can't do time travel... > > or erasing your hard disk).
You are absolutely, and potentially catastrophically, mistaken on that. Undefined behaviour does not mean "implementation specific behaviour". Nor does it mean "something sensible will happen but we don't promise what it will be". It means "the compiler can do anything", including ignoring the code you actually wrote and substituting its own faster code, which may or may not do what your original code did. We can presume that no non-malicious C compiler will *intentionally* erase your hard drive because you added 1 to an integer without checking for overflow, but it is certainly true that undefined behaviour can lead to any behaviour at all. Undefined behaviour in C is a major cause of bugs and security vulnerabilities. Raymond Chen, one of Microsoft's luminaries, describes how undefined behaviour can travel backwards in time to affect code that executes *before* the undefined behaviour occurs: https://blogs.msdn.microsoft.com/oldnewthing/20140627-00/?p=633/ Many people assume that if your code has undefined behaviour, you might have no idea what happens from that point on, but at least you can reason correctly about the state of the program prior to that. THIS IS INCORRECT. The C standard makes no such promise, and in fact explicitly states that the effect of undefined behaviour can affect code that runs before the undefined behaviour occurs. Here is an excellent three part article about undefined behaviour: http://blog.llvm.org/2011/05/what-every-c-programmer-should-know.html http://blog.llvm.org/2011/05/what-every-c-programmer-should-know_14.html http://blog.llvm.org/2011/05/what-every-c-programmer-should-know_21.html And three-parter: http://blog.regehr.org/archives/213 http://blog.regehr.org/archives/226 http://blog.regehr.org/archives/232 Bruce Dawson: https://randomascii.wordpress.com/2014/05/19/undefined-behavior-can-format-your-drive/ And I love the title of this talk from Robert C Seacord at CERT: "Dangerous Optimizations and the Loss of Causality" http://bsidespgh.com/2014/media/speakercontent/DangerousOptimizationsBSides.pdf Undefined behaviour in C is a minefield waiting to blow your program's legs off, because the designers of the language made the explicit choice that they wanted the language to be as fast and efficient as possible, even at the cost of safe, reproducible behaviour. -- Steven -- https://mail.python.org/mailman/listinfo/python-list
