1

What happens when the while(true) loop is used and no break is written inside the loop and there are some statements inside the loop? I understand that the loop will go into unending loop. But what I really want to understand is in terms of OS and SDK? Do any of them handle such a loop or system will just crash after certain time. And if they handle this, how exactly its implemented?

OT_DEV
  • 161
  • 1
  • 1
  • 10

1 Answers1

3

Depends what is in the loop. Anything that allocates memory or other resources will eventually run out of resources. What happens depends on the resource and how robust the code is (i.e. does it assume it allocated all the memory it asked for, or does it do a NULL check?)

If nothing inside the loop uses resources, there is no reason the loop will ever stop unless the user or OS kills the process.

// This will eventually crash.
while(true) {
    p = malloc(100);
    *p = 0;
}


// this will go on forever.
while(true) {
    looping = true;
}
John3136
  • 28,809
  • 4
  • 51
  • 69
  • 2
    Actually, that last loop is UB and can be entirely optimised out. Do _not_ expect it to "go on forever"! – Lightness Races in Orbit Feb 02 '15 at 00:48
  • 1
    @LightnessRacesinOrbit Why is it UB? – Pradhan Feb 02 '15 at 00:51
  • 3
    If it is optimised out, then that's a change in behaviour and so I'd argue that the optimiser is broken... (then again they are only made up examples) – John3136 Feb 02 '15 at 01:11
  • 2
    @John3136: No, it's not a change in behaviour, because the standard defines no semantics for the program. Not until you access a `volatile` object, perform I/O, perform a synchronisation/atomic operation or terminate. Abstractly, programs are supposed to return results, not sit there doing nothing forever, and C++ is defined with this in mind. – Lightness Races in Orbit Feb 02 '15 at 14:42
  • 1
    @LightnessRacesinOrbit The only thing that can be optimized out is the assignment in the loop. No matter how smart the compiler is, it will never optimize control flow in a way that makes infinite loops undefined. There are legitimate reasons to have them. – Dougvj Feb 02 '15 at 19:51
  • 3
    @Dougvj: You're not listening, and you're not reading. I linked Pradhan to the _quote from the standard_ that is the authority on this matter. Your opinion on what the optimiser should or should not do is entirely irrelevant. Neither does the compiler choose what is and is not undefined based on how "smart" it is. – Lightness Races in Orbit Feb 02 '15 at 23:16
  • 1
    @LightnessRacesinOrbit You're correct, I didn't see the link. I apologize. This certainly didn't used to be the case at least in C, so hence my own confusion. My reference to the compiler being smart was precisely as you stated, that it doesn't give the compiler license to break the standard. – Dougvj Feb 03 '15 at 02:51
  • 2
    @Dougvj: No, indeed, C is an entirely different language. :) – Lightness Races in Orbit Feb 03 '15 at 10:19
  • 4
    According to the C++ Standard, the assumption that a program will eventually do something that results in observable behavior "*is intended to allow compiler transformations such as removal of empty loops, even when termination cannot be proven.*" – Andy Prowl Feb 03 '15 at 10:28