bob wrote:I DO understand what it means (which, by the way, does not match much of what I have read here). This "demons" nonsense is just that. Unless you REALLY believe that a strcpy(a, a+1) is allowed to format your hard disk or any other equally damaging act.
You clearly don't understand it then. It is definitely allowed to format your hard disk. Nobody would ever make a compiler that does that on purpose, but how could they possibly guarantee it won't happen by accident? The standard
makes no promises whatsoever about what will happen if you try execute undefined behavior in a program. It could fail before, after or during the undefined operation. It could abort with an error message, it could silently do something mysterious and surprising, it could silently do what you (for some reason) expected it to do, or it could silently format your hard drive.
bob wrote:I don't buy that, and would call that an outright stupid opinion. The generally accepted definition of undefined behavior is that anything can happen, but within the scope of the operation being performed, ONLY.
No, wrong!! There is no such "scope of the operation being performed". By invoking undefined behavior, you left the realm of C programs and entered a bizarre netherworld, where
anything at all might happen. And there's a specific reason for this, too. Its so the compiler writers and library authors don't have to care about what happens when your program tries to do one of these illegal, undefined things. The compiler can optimize your program assuming
any undefined behavior can't happen. In practice that can mean anything from replacing sensible-looking-but-undefined comparisons with "1", to deleting entire blocks of code. (Chris Lattner explains that LLVM used to just silently delete the code, but now they usually try and put a trapping instruction in there instead... even though it makes the code size bigger, apparently programmers found it too confusing when the program just fell out of the end of a function that had invoked undefined behavior and started executing whatever function came next in the compiled code...)
bob wrote:That is, an overlapping string might overwrite a buffer, or it might not, but it won't do anything INTENTIONALLY worse.
Well, it probably won't do anything intentionally malicious... but after inlining, macro substitution, and other transformations by the optimizer, even non-malicious optimization can have
very surprising effects on your program's behavior. And this happens all the time to buggy programs, and the programmers sometimes even report those as bugs against the compiler even though the actual bug is in their program.