At what point in the loop does integer overflow become undefined behavior?
This is an example to illustrate my question which involves some much more complicated code that I can't post here.
#include <stdio.h>
int main()
{
int a = 0;
for (int i = 0; i < 3; i++)
{
printf("Hellon");
a = a + 1000000000;
}
}
This program contains undefined behavior on my platform because a will overflow on the 3rd loop.
Does that make the whole program have undefined behavior, or only after the overflow actually happens ? Could the compiler potentially work out that a will overflow so it can declare the whole loop undefined and not bother to run the printfs even though they all happen before the overflow?
(Tagged C and C++ even though are different because I'd be interested in answers for both languages if they are different.)
If you're interested in a purely theoretical answer, the C++ standard allows undefined behaviour to "time travel":
[intro.execution]/5: A conforming implementation executing a well-formed program shall produce the same observable behavior as one of the possible executions of the corresponding instance of the abstract machine with the same program and the same input. However, if any such execution contains an undefined operation, this International Standard places no requirement on the implementation executing that program with that input (not even with regard to operations preceding the first undefined operation)
As such, if your program contains undefined behaviour, then the behaviour of your whole program is undefined.
First, let me correct the title of this question:
Undefined Behavior is not (specifically) of the realm of execution.
Undefined Behavior affects all steps: compiling, linking, loading and executing.
Some examples to cement this, bear in mind that no section is exhaustive:
LD_PRELOAD tricks on Unixes This is what is so scary about Undefined Behavior: it is nigh impossible to predict, ahead of time, what exact behavior will occur, and this prediction has to be revisited at each update of the toolchain, underlying OS, ...
I recommend watching this video by Michael Spencer (LLVM Developer): CppCon 2016: My Little Optimizer: Undefined Behavior is Magic.
An aggressively optimising C or C++ compiler targeting a 16 bit int will know that the behaviour on adding 1000000000 to an int type is undefined.
It is permitted by either standard to do anything it wants which could include the deletion of the entire program, leaving int main(){} .
But what about larger int s? I don't know of a compiler that does this yet (and I'm not an expert in C and C++ compiler design by any means), but I imagine that sometime a compiler targeting a 32 bit int or higher will figure out that the loop is infinite ( i doesn't change) and so a will eventually overflow. So once again, it can optimise the output to int main(){} . The point I'm trying to make here is that as compiler optimisations become progressively more aggressive, more and more undefined behaviour constructs are manifesting themselves in unexpected ways.
The fact that your loop is infinite is not in itself undefined since you are writing to standard output in the loop body.
链接地址: http://www.djcxy.com/p/14026.html