Bug 18598 – cyclic constructor calls have undefined behavior but are accepted in @safe code

On class constructors, the spec says [1]: > It is illegal for constructors to mutually call each other, although > the compiler is not required to detect it. It will result in undefined > behavior. But DMD accepts this: ---- class C { this() @safe { this(1); } this(int i) @safe { this(); } } void main() @safe { auto c = new C; } ---- According to the spec, the code has undefined behavior, so it shouldn't be accepted with the @safe attribute. Also according to the spec, "the compiler is not required to detect" this, but that can't apply to @safe code, because the compiler is required to ensure that there is "no possibility of undefined behavior" in @safe code [2]. (As always, this can be fixed by letting DMD reject the code, or by changing the spec to give the code defined behavior.) [1] https://dlang.org/spec/class.html#constructors [2] https://dlang.org/spec/function.html#function-safety

I don't know a way to assign defined behavior to overflowing the stack :-( This can, however, be statically detected by the compiler by keeping track of the calls between constructors. (They can't be virtual, so that'll work as long as all the constructor bodies are visible to the compiler.)

(In reply to Walter Bright from comment #1) > I don't know a way to assign defined behavior to overflowing the stack :-( Is that a problem for normal (non-constructor) functions as well? ---- void f() @safe { g(); } void g() @safe { f(); } void main() @safe { f(); } /* Undefined behavior? */ ----

(In reply to ag0aep6g from comment #2) > Is that a problem for normal (non-constructor) functions as well? Yes. I'm open to advice on what to do about it.

(In reply to Walter Bright from comment #3) > I'm open to advice on what to do about it. I'm by no means an expert here, but don't we have a guaranteed guard page beyond the stack? If we have, stack overflow is guaranteed to fail with a segfault, as long as the access doesn't jump over guard page (cf. issue 17566). The situation is very similar to null dereferences then. A null dereference also hits a guard page, as long as the offset from null isn't too large (cf. issue 5176). In both cases, the compiler has to detect offsets that are so large that they would jump over the guard page, and then it has to inject code that makes an earlier access to trigger the segfault. If I got the term right, for the stack that's called "stack probing".

Well, infinite recursion also leads to a segfault due to stack overflow however it is still accepted in @safe code [1]. @safe typically refers to undefined behavior caused by memory corruption. I don't see any memory corruption happening here, since the OS guards against that, rather a programming mistake that is beyond of what the @safe checking mechanism can discover. [1] void fun() @safe { fun();

THIS ISSUE HAS BEEN MOVED TO GITHUB https://github.com/dlang/dmd/issues/19408 DO NOT COMMENT HERE ANYMORE, NOBODY WILL SEE IT, THIS ISSUE HAS BEEN MOVED TO GITHUB