← Back to context

Comment by account42

19 hours ago

Unfortunate. There isn't ever a good reason to have an infinite loop so concerned compilers could have just diagnosed this as a warning.

16 comments

account42

Reply
echoangle  18 hours ago

The article mentions a use case for that:

> What I found is that this is common in embedded and kernel code as a halt-on-error pattern. When a fatal error occurs and there’s no operating system to exit to, you simply stop:

  • pdonis  18 hours ago

    If this is a genuine use case, I wonder why the language can't just introduce a built-in function for it. For example, std::get_stuck_here(). Then the compiler would know not to optimize this away. The implementation under the hood could still be an infinite loop, but the compiler would not have to guess why it's there.

    • gpderetta  12 hours ago

      one could already add loads off a volatile and portably prevent the loop from being optimized. But there was already a lot of existing embedded code that had this sort of loop, (and more will be written as it is an existing idiom) which the committee wanted to un-break.

  • account42  18 hours ago

    Low level code can and should use assembly to get the precise effect they desire in these cases.

sumtechguy  18 hours ago

> There isn't ever a good reason to have an infinite loop

That seems to be a very broad statement. For example in a system where interrupts mostly control things this sort of 'do not close the program' could be useful.

A guy I worked with had one I never would think of because I do not work in that field.

But yeah a warning would probably be useful.

weinzierl  18 hours ago

For Rust the infinite loop is important enough to have its own keyword.

  • kibwen  17 hours ago

    The reason for this is interesting. Loop constructs that you're guaranteed to enter have implications for control flow (in every language, not just Rust). It means that the following program is valid in Rust:

        let x; // declared, but uninitialized variable
    loop { // control flow is guaranteed to enter this loop
        if some_condition() {
            x = 42; // initialize x
            break;
        }
    }
    foo(x); // Rust knows that x is initialized as of here in all possible paths

    In contrast, while loops check their condition before entering, which means the entire loop body might be skipped. Languages which guarantee initialization-before-use might special-case certain conditions for while loops as a hint to the control flow analysis (e.g. Java special-cases `while(true)`), but obviously this doesn't generalize to arbitrary conditions.

    Interestingly, this all suggest that, in C-like languages, the more natural implementation of an infinite loop should not be `while(true)` nor `for(;;)`, but rather `do {} while(true)`, because do-while are also guaranteed to enter their body (and note that Rust doesn't feature do-while loops).