3 ms·
The biggest problem is, the most classic C bug is writing an array out of bounds. It would be almost impossible to efficiently add bounds checking to all C arra
by CJefferson 8y ago
The biggest problem is, the most classic C bug is writing an array out of bounds. It would be almost impossible to efficiently add bounds checking to all C arrays, so let's assume we are going to leave that as undefined behaviour.
That out of bounds write could go anywhere. Into any other variable. Changing the code of the program (if it isn't write protected). So the most common C bug can lead to absolutely any change (hypothetically) to the running program.
That's one of the reasons writing text to "explain" what undefined behaviour can do is so hard.
- jzwinck 8y agoWhat many people don't expect is that if the compiler can prove that some function invokes undefined behavior, the compiler can emit no code for it at all--before, during, and after the UB expression. Saying that writing past the end of an array could modify any other variable is one thing. Saying that writing past the end of an array could make your entire program do nothing is quite another.
- mpweiher 8y agoWhat you describe is pretty much exactly the range of "undefined" behavior one would expect, and also in the range of what used to be "permissible": you just write to that address What happens then is hard to predict, and therefore in a sense the behavior after that becomes "undefined". This is fine. What's not fine is the compiler taking some action other than 1. just writing to that address (ignoring), or 2. emitting a compiler error and terminating, or 3. doing something else that is "characteristic" of the environment, and documenting it Current optimizing compilers don't do any of these things, and also not something that in any way resembles any of these options.