digitalmars.D.bugs - [Issue 2678] New: for loops are already assumed to terminate
- d-bugmail puremagic.com (31/31) Feb 20 2009 http://d.puremagic.com/issues/show_bug.cgi?id=2678
- d-bugmail puremagic.com (4/6) Feb 20 2009 s/Turing completeness/Turing's machine halting problem/
- d-bugmail puremagic.com (7/7) Feb 20 2009 http://d.puremagic.com/issues/show_bug.cgi?id=2678
- d-bugmail puremagic.com (6/11) Feb 20 2009 http://d.puremagic.com/issues/show_bug.cgi?id=2678
- d-bugmail puremagic.com (6/6) Mar 03 2009 http://d.puremagic.com/issues/show_bug.cgi?id=2678
- d-bugmail puremagic.com (4/4) Mar 05 2009 http://d.puremagic.com/issues/show_bug.cgi?id=2678
- d-bugmail puremagic.com (8/8) Mar 06 2009 http://d.puremagic.com/issues/show_bug.cgi?id=2678
- d-bugmail puremagic.com (9/9) Mar 11 2009 http://d.puremagic.com/issues/show_bug.cgi?id=2678
http://d.puremagic.com/issues/show_bug.cgi?id=2678 Summary: for loops are already assumed to terminate Product: D Version: unspecified Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P2 Component: DMD AssignedTo: bugzilla digitalmars.com ReportedBy: andrei metalanguage.com 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". --
Feb 20 2009
http://d.puremagic.com/issues/show_bug.cgi?id=2678Before anyone brings up Turing completeness: I said "nonzero compile-time-constant termination condition".s/Turing completeness/Turing's machine halting problem/ --
Feb 20 2009
http://d.puremagic.com/issues/show_bug.cgi?id=2678 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) --
Feb 20 2009
http://d.puremagic.com/issues/show_bug.cgi?id=2678You 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. --
Feb 20 2009
http://d.puremagic.com/issues/show_bug.cgi?id=2678 This also applies to: while(1) {...} But I notice that Walter's already fixed that <g>. --
Mar 03 2009
http://d.puremagic.com/issues/show_bug.cgi?id=2678 How about assert(0); at the end? --
Mar 05 2009
http://d.puremagic.com/issues/show_bug.cgi?id=2678 smjg iname.com changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |smjg iname.com That should equally generate an unreachable code warning. --
Mar 06 2009
http://d.puremagic.com/issues/show_bug.cgi?id=2678 bugzilla digitalmars.com changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED Fixed dmd 1.041 and 2.026 --
Mar 11 2009