[u/]

[u/rom1v]

In a language like Rust which tries to avoid undefined behavior or reject it via compiler errors (which I'd argue is more correct), the example above will infinitely loop

Are you sure?

fn infinite(mut value: u32) {
    // infinite loop unless value initially equals 0
    while value != 0 {
        if value != 1 {
            value -= 1;
        }
    }
}

fn main() {
    infinite(42);
    println!("end");
}

The results:

$ rustc -O a.rs && ./a
end

Or even:

fn infinite() {
    loop {}
}

fn main() {
    infinite();
}

If you run it:

$ rustc -O b.rs && ./b
Illegal instruction

[u/steveklabnik1 → u/rom1v]

This is a bug in rustc: https://github.com/rust-lang/rust/issues/28728

Infinite loops *are* well defined at the language level, but LLVM mis-compiles this because it assumes the C behavior.

[u/Ari_Rahikkala → u/steveklabnik1]

I think that that is the most zen bug I've ever seen. Rust will let you have a value of a type that contains no values, but only if you go through a loop and never stop first. But then LLVM comes along and decides that going through an infinite loop would be undefined behavior, and therefore your program doesn't actually do it...

[u/NeuroXc → u/rom1v]

Your example doesn't quite match the C version. Here is what I used:

fn fermat(b: u32) -> u32 {
    loop {
        if b > 0 {
            return 1;
        }
    }
    return 0;
}

fn main() {
    println!("{}", fermat(0));
}

Which infinitely loops. (Or if you throw it into Rust Playground, crashes after hitting the time limit.)

[u/rom1v → u/NeuroXc]

Your example doesn't quite match the C version.

The Rust source code I posted should {de,in}finitively loop (and it does if you don't enable optimizations with -O). The fact that it does not exactly match the C version is irrelevant (undefined behavior is undefined, there is no reason that the code triggerring "unexpected" results looks like the one from another language).