2 ms·

No. In fact for example the C++ standard says such a loop can be optimized away by the compiler, even if syntax suggests it is an infinite loop.

by kccqzy 2y ago

kibwen 2y ago
> No. This isn't quite correct, as demonstrated by the example of C++, because the act of turning a function that never halts (i.e. a function that is guaranteed to diverge) into a function that might halt is an observable effect. Rust actually relies on the fact that infinite loops are infinite, and they had to submit patches to LLVM to make it possible for languages to opt out of C++-style semantics: https://github.com/rust-lang/rust/issues/28728 https://github.com/rust-lang/rust/issues/28728
jkrejcha 2y ago
C++ is pretty unique in considering infinite loops without side effects undefined behavior. It's allowed in C[1] as well as pretty much all mainstream programming languages from the low level to the high level (for good reason). Furthermore, there's an active proposal to match C by removing this undefined behavior in the cases C does[2]. Even in C++, it's uncommon for compilers to exploit it (especially in the trivial case) probably because, even if it's undefined, generally such behavior are pretty surprising and unexpected (and programmers do write infinite loops on purpose!). Having non-effect producing infinite loops is useful (and sometimes is the only safe way of performing an operation), especially in some low level code. Another commenter pointed out the idea of delays in microcontrollers[3] but I want to provide an example from operating systems. Take for example a panic function. At the end of it, you usually have an infinite loop of some sort, partly because you can't really safely do too much and panics generally represent a completely unrecoverable state from the operating system's point of view. A trivial for (;;) {} ...is useful. [1]: For constant expressions. [2]: https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2023/p2809r1.html https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2023/p28... [3]: https://news.ycombinator.com/item?id=40542860 https://news.ycombinator.com/item?id=40542860

No. In fact for example the C++ standard says such a loop can be optimized away by the compiler, even if syntax suggests it is an infinite loop.

by kccqzy 2y ago

No. In fact for example the C++ standard says such a loop can be optimized away by the compiler, even if syntax suggests it is an infinite loop.

kibwen 2y ago

> No. This isn't quite correct, as demonstrated by the example of C++, because the act of turning a function that never halts (i.e. a function that is guaranteed to diverge) into a function that might halt is an observable effect. Rust actually relies on the fact that infinite loops are infinite, and they had to submit patches to LLVM to make it possible for languages to opt out of C++-style semantics: https://github.com/rust-lang/rust/issues/28728 https://github.com/rust-lang/rust/issues/28728

jkrejcha 2y ago

C++ is pretty unique in considering infinite loops without side effects undefined behavior. It's allowed in C[1] as well as pretty much all mainstream programming languages from the low level to the high level (for good reason). Furthermore, there's an active proposal to match C by removing this undefined behavior in the cases C does[2]. Even in C++, it's uncommon for compilers to exploit it (especially in the trivial case) probably because, even if it's undefined, generally such behavior are pretty surprising and unexpected (and programmers do write infinite loops on purpose!). Having non-effect producing infinite loops is useful (and sometimes is the only safe way of performing an operation), especially in some low level code. Another commenter pointed out the idea of delays in microcontrollers[3] but I want to provide an example from operating systems. Take for example a panic function. At the end of it, you usually have an infinite loop of some sort, partly because you can't really safely do too much and panics generally represent a completely unrecoverable state from the operating system's point of view. A trivial for (;;) {} ...is useful. [1]: For constant expressions. [2]: https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2023/p2809r1.html https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2023/p28... [3]: https://news.ycombinator.com/item?id=40542860 https://news.ycombinator.com/item?id=40542860