Bug 2678 – for loops are already assumed to terminate

Consider this code compiled with -w: int main() { int i; for (;; ++i) { if (i == 10) return 0; } i += 100; } This loop never reaches its end. However the compiler does not detect that and spuriously asks for a return at the end of the function. Worse, if there is some unreachable code following the loop, it does not recognize that. All loops that (a) have no termination condition or a nonzero compile-time-constant termination condition, and (b) do not embed any "break" statement - should be understood as loops that do not fall through. Before anyone brings up Turing completeness: I said "nonzero compile-time-constant termination condition".

> Before anyone brings up Turing completeness: I said "nonzero > compile-time-constant termination condition". s/Turing completeness/Turing's machine halting problem/

You would also need to take into account try/catch blocks. This doesn't actually invalidate the assertion (you still can't fall out of the loop), it just forces you to be more careful how you read it (you /can/ end up running the next line of code after the loop if it is in a catch block)

(In reply to comment #2) > You would also need to take into account try/catch blocks. This doesn't > actually invalidate the assertion (you still can't fall out of the loop), it > just forces you to be more careful how you read it (you /can/ end up running > the next line of code after the loop if it is in a catch block) > Yah, and goto is to be handled as well. I'm just saying the loop will never naturally fall off its end.

This also applies to: while(1) {...} But I notice that Walter's already fixed that <g>.

How about assert(0); at the end?

That should equally generate an unreachable code warning.

Fixed dmd 1.041 and 2.026