www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.bugs - [Issue 2678] New: for loops are already assumed to terminate

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


-- 
Feb 20 2009
next sibling parent 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/ --
Feb 20 2009
prev sibling next sibling parent 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) 


-- 
Feb 20 2009
prev sibling next sibling parent 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. --
Feb 20 2009
prev sibling next sibling parent 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>.


-- 
Mar 03 2009
prev sibling next sibling parent 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?


-- 
Mar 05 2009
prev sibling next sibling parent 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.


-- 
Mar 06 2009
prev sibling parent 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


-- 
Mar 11 2009