https://issues.dlang.org/show_bug.cgi?id=14419

--- Comment #11 from Ketmar Dark <ketmar@ketmar.no-ip.org> ---
(In reply to Jens Bauer from comment #10)
> (This particular web-browser
> actually *had* a loop detection on the Javascript, and it was impossible for
> me to trick it).

it's very easy to trick any endless loop detection code: just start computing PI. ;-)

--

https://issues.dlang.org/show_bug.cgi?id=14419

--- Comment #12 from Jens Bauer <jens-bugzilla@gpio.dk> ---
(In reply to Ketmar Dark from comment #3)
> alias extern(C) immutable void function () VectorFunc;
> VectorFunc[3] g_pfnVectors = [
>   Reset_Handler,
> ];
> 
> extern(C) void Reset_Handler () {
>   while (true) {}
> }
> 
> there is no sense to evaluate `Reset_Handler`, as it's return value (actually, absense of) is not suitable as array element.

There is another detail here, which I just noticed:
In the array, I do not give the function any arguments / parameters.

-Shouldn't that be reported as an error, or is it intended that functions are
callable like this:
a = printf;

... ?

In C, a would be a pointer to the function printf, however in D, a would contain the result of the execution.

--

https://issues.dlang.org/show_bug.cgi?id=14419

--- Comment #13 from Steven Schveighoffer <schveiguy@yahoo.com> ---
(In reply to Jens Bauer from comment #12)
> There is another detail here, which I just noticed:
> In the array, I do not give the function any arguments / parameters.
> 
> -Shouldn't that be reported as an error, or is it intended that functions
> are callable like this:
> a = printf;
> 
> ... ?
> 
> In C, a would be a pointer to the function printf, however in D, a would contain the result of the execution.

That is intended, you can call a function without parameters by omitting any parentheses. To get the address of a function, you must use the & operator.

--

https://issues.dlang.org/show_bug.cgi?id=14419

yebblies <yebblies@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |yebblies@gmail.com

--- Comment #14 from yebblies <yebblies@gmail.com> ---
(In reply to Martin Nowak from comment #9)
> If you really think we should fix this, then a time limit for CTFE execution might be feasible.

An iteration limit would be better than a time limit, because it will not be dependent on environmental conditions.  This would need to be configurable from the command line etc.

The compilation would terminate with a nice stack trace, making it easy to debug.

(In reply to Jens Bauer from comment #10)
> 1: on dlang.org, there's an on-line compiler. It wouldn't take much effort to bring it to the knees.

It's trival to make a D program that will take a very very long time to compile, even without infinite loops.

--

https://issues.dlang.org/show_bug.cgi?id=14419

--- Comment #15 from Iain Buclaw <ibuclaw@gdcproject.org> ---
(In reply to yebblies from comment #14)
> (In reply to Martin Nowak from comment #9)
> > If you really think we should fix this, then a time limit for CTFE execution might be feasible.
> 
> An iteration limit would be better than a time limit, because it will not be dependent on environmental conditions.  This would need to be configurable from the command line etc.
> 
> The compilation would terminate with a nice stack trace, making it easy to debug.
> 

So then you just need to decide what is a suitable iteration limit, short.max? ushort.max?

--

https://issues.dlang.org/show_bug.cgi?id=14419

--- Comment #16 from Jens Bauer <jens-bugzilla@gpio.dk> ---
(In reply to Iain Buclaw from comment #15)
> So then you just need to decide what is a suitable iteration limit, short.max? ushort.max?

If it's just to make sure that "we're not stuck forever", the size of the
returned argument might be suitable.
I believe this is very much a matter of opinion, though.

But consider this. Combining with my previous idea of checking the
exit-conditions.
All sources for the exit-conditions should be saved (the stack would be fine):
All minimum values for the exit conditions
All maximum values for the exit conditions
A minimumHit counter
A maximumHit counter
Each time the same minimum for all exit conditions are hit, then the minimumHit
counter is incremented.
If a new minimum is found, the minimumHit counter is cleared.
Same thing for the maximumHit counter.
Now if any of those two counters reach a value above - say 10, then we'll exit
the loop.

As a fail-safe, an unsigned 32-bit counter could be used as an 'absolutely maximum limit'.

This is just an idea, but I believe it would be fairly good at catching more than 99% of the lockups.

--

https://issues.dlang.org/show_bug.cgi?id=14419

--- Comment #17 from Jens Bauer <jens-bugzilla@gpio.dk> ---
(In reply to Jens Bauer from comment #16)
> As a fail-safe, an unsigned 32-bit counter could be used as an 'absolutely maximum limit'.
... and if the 32-bit counter wraps, then an error message should be given to the user, for instance: "Error: Please write better code." ;)

--

https://issues.dlang.org/show_bug.cgi?id=14419

Andrei Alexandrescu <andrei@erdani.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Version|D1 & D2                     |D2

--

https://issues.dlang.org/show_bug.cgi?id=14419

Iain Buclaw <ibuclaw@gdcproject.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P1                          |P4

--

https://issues.dlang.org/show_bug.cgi?id=14419

--- Comment #18 from dlangBugzillaToGithub <robert.schadek@posteo.de> ---
THIS ISSUE HAS BEEN MOVED TO GITHUB

https://github.com/dlang/dmd/issues/17703

DO NOT COMMENT HERE ANYMORE, NOBODY WILL SEE IT, THIS ISSUE HAS BEEN MOVED TO GITHUB

--