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".


-- 

http://d.puremagic.com/issues/show_bug.cgi?id=2678





------- Comment #1 from andrei@metalanguage.com  2009-02-20 09:17 -------
> Before anyone brings up Turing completeness: I said "nonzero compile-time-constant termination condition".

s/Turing completeness/Turing's machine halting problem/


-- 

http://d.puremagic.com/issues/show_bug.cgi?id=2678





------- Comment #2 from shro8822@vandals.uidaho.edu  2009-02-20 10:52 -------
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)


-- 

http://d.puremagic.com/issues/show_bug.cgi?id=2678





------- Comment #3 from andrei@metalanguage.com  2009-02-20 11:27 -------
(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.


-- 

http://d.puremagic.com/issues/show_bug.cgi?id=2678





------- Comment #4 from clugdbug@yahoo.com.au  2009-03-03 07:49 -------
This also applies to:
while(1) {...}

But I notice that Walter's already fixed that <g>.


-- 

http://d.puremagic.com/issues/show_bug.cgi?id=2678





------- Comment #5 from baryluk@smp.if.uj.edu.pl  2009-03-05 16:56 -------
How about assert(0); at the end?


-- 

http://d.puremagic.com/issues/show_bug.cgi?id=2678


smjg@iname.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |smjg@iname.com




------- Comment #6 from smjg@iname.com  2009-03-06 14:56 -------
That should equally generate an unreachable code warning.


-- 

http://d.puremagic.com/issues/show_bug.cgi?id=2678


bugzilla@digitalmars.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED




------- Comment #7 from bugzilla@digitalmars.com  2009-03-11 14:54 -------
Fixed dmd 1.041 and 2.026


--