CODEWITHSUNDEEP
c++language-lawyerundefined-behavior
bolov
bolov

Reputation: 75697

Is a program that never terminates a valid C++ program?

Is a program required to terminate? In other words is a program that that runs forever technically Undefined Behavior? Note this is not about empty loops. Talking about programs that do "stuff" (i.e. observable behavior) forever.

E.g. something like this:

int main()
{
    while (true)
    {
        try
        {
            get_input(); // calls IO
            process();
            put_output(); // calls IO, has observable behavior

            // never break, exit, terminate, etc
        } catch(...)
        {
            // ignore all exceptions
            // don't (re)throw
            // never go out of loop
        }
    }
}

This is more of an academic question, as empirically all sane compilers will generate expected code for the above kind of program (assuming of course no other source of UB). And yes, of course there are a lot of programs that never terminate (os, embeded, servers). However the standard is quirky sometimes, thus the question.

Tangential: many (some?) definitions of "algorithm" require that an algorithm must terminate, i.e. a series of operations that never terminates is not considered an algorithm.

Tangential. The halting problem states that there cannot exist an algorithm to determine if an arbitrary program finishes for an input. However for this particular program since there is no branch that leads to getting out of main, the compiler can easily determine the program will never end. This is however irrelevant as the question is language-lawyer.

Upvotes: 16

Views: 1718

Answers (2)

Daniel H
Daniel H

Reputation: 7433

There is nothing in the C++ standard that requires the program, or any given thread, to terminate. The closest thing to that is [intro.progress]p1, which says

The implementation may assume that any thread will eventually do one of the following:

  • terminate,
  • make a call to a library I/O function,
  • perform an access through a volatile glvalue, or
  • perform a synchronization operation or an atomic operation.

[ Note: This is intended to allow compiler transformations such as removal of empty loops, even when termination cannot be proven.  — end note ]

As long as there is some observable behavior, eventually, or as long as it spends all its time blocked on an I/O operation or another blocking library call, this doesn't apply, and the program is valid (assuming it meets all the other validity criteria).

Upvotes: 16

Caleth
Caleth

Reputation: 62684

Yes. From [intro.progress]

The implementation may assume that any thread will eventually do one of the following:

  • terminate,
  • make a call to a library I/O function,
  • perform an access through a volatile glvalue, or
  • perform a synchronization operation or an atomic operation.

[ Note: This is intended to allow compiler transformations such as removal of empty loops, even when termination cannot be proven. — end note ]

Upvotes: 4

Related Questions