• d-bugmail puremagic.com Feb 20 2009
• d-bugmail puremagic.com Feb 20 2009
• d-bugmail puremagic.com Feb 20 2009
• d-bugmail puremagic.com Feb 20 2009
• d-bugmail puremagic.com Mar 03 2009
• d-bugmail puremagic.com Mar 05 2009
• d-bugmail puremagic.com Mar 06 2009
• d-bugmail puremagic.com Mar 11 2009

d-bugmail puremagic.com writes:

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


-- 

d-bugmail puremagic.com writes:

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/


-- 

d-bugmail puremagic.com writes:

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) 


-- 

d-bugmail puremagic.com writes:

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.


-- 

d-bugmail puremagic.com writes:

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


-- 

d-bugmail puremagic.com writes:

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?


-- 

d-bugmail puremagic.com writes:

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.


-- 

d-bugmail puremagic.com writes:

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


--