Hacker News Reader

Comment by volta87 | Hacker News Reader

Notice that in C and C++ loops that might not terminate are UB, while in Rust they are just infinite loops.

So there is a significant difference in semantics between Rust and C/C++ here.

C and C++ actually differ in semantics here; C allows infinite loops that are controlled by a constant expression.

Generally, yes. Though, as always, these things are hard to summarize in one sentence and depend on the standard version (pre/post C++11). This post might shed some light on the options we are considering for Clang right now: https://reviews.llvm.org/D94367#2489090

Just what is gained by failing to loop forever? It seems like a really low-value optimization. Nearly always, the optimization would violate the programmer's intent or it would change an ordinary bug into a confusing bug. An infinite loop is not very many bytes on any processor.

The standard may allow the generation of insane code, but a decent-quality compiler does not do so. The standard ought to be fixed.

The infinite loop being UB was added because it prevents some important code motion optimizations and makes it hard to reason about the memory model. You can find the details on the papers leading to the C++11 memory model.

Uh, so what?

Letting the compiler assume that a "switch" without a default will never go there is a great optimization too. Why not put that in the standard?

Actually, this is worse. Letting the loop be UB is like letting a true "if" be UB. Just never mind the code actually written; surely it doesn't mean what it says.

> Letting the compiler assume that a "switch" without a default will never go there is a great optimization too. Why not put that in the standard?

that's actually the case already. A missing default is UB if the switch condition does not match any of the cases. And C compilers already optimize accordingly.

> The infinite loop being UB was added because it prevents some important code motion optimizations

Which ones?

If this optimizations are so important, how come Rust was designed in such a way to make them impossible? Also, how does this fit, e.g., the benchmark game results which show that Rust is faster than C for all benchmarks considered there ?

Store sinking for example, which is unsafe unless the loop is guaranteed to terminate.

C does not have this guarantee (at least not in all cases). Also rust is compiled with the llvm backend, so my understanding is that in practice rust assumes that loops terminate. See:

https://github.com/rust-lang/rust/issues/28728

There are llvm directives that can be added to prevent the optimization, but they are rejected by the rust maintainers exactly because they would cause performance regressions.

Loops that do nothing and don't terminate.

If your loop infinitely writes the number 70 to an atomic int, it's fine.

If by "nothing" you mean "nothing but looping", then yes, you are right. Any loop that "just loops" is doing something by definition: looping.

It depends on your perspective. Normally when I talk about what a loop "does", I am talking purely about the contents of the loop.

Reply on news.ycombinator.com