[Issue 14419] [CTFE] Need infinite loop detection?

https://issues.dlang.org/show_bug.cgi?id=14419 Jens Bauer <jens-bugzilla@gpio.dk> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |jens-bugzilla@gpio.dk --- Comment #1 from Jens Bauer <jens-bugzilla@gpio.dk> --- Luckily you just prevented me from pressing "Submit Issue" in filing a duplicate by approximately 1 second! Some further thoughts: In the particular code snippet, my 'Reset_Handler' does not return a value. Since D specifies that a void is the same as int returning 0, then it would make sense to completely avoid evaluating functions that return 'void', and just insert a 0 in the array instead, possibly giving an error or warning. This would also speed up build time for other functions. -Thinking a bit further: What if something else was initialized by a list of functions returning void in an array - that's abusing the functionality and I do not know if it's possible to do so. --

https://issues.dlang.org/show_bug.cgi?id=14419 --- Comment #2 from Kenji Hara <k.hara.pg@gmail.com> --- (In reply to Iain Buclaw from comment #0) > This was noticed and raised in GDC Bugzilla #178 because of a typo in the code. > > http://bugzilla.gdcproject.org/show_bug.cgi?id=178 > > > What it boils down to is this: > --- > int foo() { while (true) { } return 1; } > enum bar = foo; // User meant to type '&foo' > --- > > Perfectly valid code causing an infinite loop in CTFE. Obviously this is a bug vs. feature argument, but infinite loop detection should really be a feature of CTFE to avoid accidental build bugs from occurring. How to do it for a complex code? int foo(int n = 0) { while (true) { ++n; if (n > 1_000_000) break; } return 1; } enum bar = foo; // User meant to type '&foo' Using while(true) for the limited loop is usual. And limiting loop repetition to arbitrary count is problematic (a million repetition is too big?). The idea sounds good, but implementing it would be difficult. --

https://issues.dlang.org/show_bug.cgi?id=14419 --- Comment #3 from Ketmar Dark <ketmar@ketmar.no-ip.org> --- at least there is sense to make CTFE fail early when it tries to evaluate function with inappropriate return value. the original sample was this: 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. --

https://issues.dlang.org/show_bug.cgi?id=14419 --- Comment #4 from Ketmar Dark <ketmar@ketmar.no-ip.org> --- ah, Jens already wrote about it. i really have to learn to read all the answers three times before posting my own! --

https://issues.dlang.org/show_bug.cgi?id=14419 --- Comment #5 from Kenji Hara <k.hara.pg@gmail.com> --- (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) {} > } It's another issue in the process of initializer semantic. Essentially it should make a type error: Reset_Handler() is void and has no value, but current dmd prematurely runs CTFE. --

https://issues.dlang.org/show_bug.cgi?id=14419 --- Comment #6 from Jens Bauer <jens-bugzilla@gpio.dk> --- (In reply to Kenji Hara from comment #2) > How to do it for a complex code? > > int foo(int n = 0) > { > while (true) > { > ++n; > if (n > 1_000_000) > break; > } > return 1; > } > enum bar = foo; // User meant to type '&foo' I would check if the 'exit' condition changes. When the code is compiled, it boils down to two or three interesting assembly-languge instructions: 1: compare 2: conditional branch forward 3: branch always backward If the argument to 'compare' changes, then the loop would most likely not be infinite and thus most likely be safe to execute. There might be multiple conditions, though, which makes things a bit more complex. However, I sense that there might be possible ways that the condition could change on every compare, where it wouldn't be safe to just check for changes. Example: int Init_element(n) { l = 17; while(1) { n = 3 - n; if(n == 0) break; l *= 31415927; } return(l); } Because of the 'toggling', the compiler might not be able to predict that this keeps going on for eternity. Such cases are of course rare, but should still be considered. --