(Sorry for the very delayed answers.)
----------------
Walter Bright:
Oh well, there goes about 90% of D programs and pretty much all
use of the D runtime library!
Right. On the other hand the need for such strict safety
requirements that forbid stack overflows, is not present in
desktop software, it's for uncommon systems, with limited
resources, that need to work reliably, like some car/plane
electronics.
So when you have such needs you are willing to throw away 90% of
D libs/Phobos, and probably to not use d-runtime too :-) And in
such cases it's good to have as much compile-time assurances as
possible.
And I suspect the subset of D programs
that don't have indirection or recursion is so small as to not
be worth the bother.
I do know there are a class of applications, for example in
critical embedded
systems, were recursion and indirection, and even allocation,
are not allowed.
Using D in such cases would require eschewing using Phobos, and
some other care
taken,
Right. And people in such fields are looking for something safer
and nicer than C + a ton of static tests (and many of them don't
seem to love Ada).
----------------
Andrei Alexandrescu:
My understanding is that it can be done but only with
annotations or whole program analysis.<
I agree. But people in (example) automotive industry could be
(and probably are) willing to do both.
Thus is a specialized niche, so adding such annotations to D
language seems too much. So I've suggested to add enough static
introspection (and some way to attach compile-time semantics to
UDAs) to allow specialized programmers to add to D those
annotations (and leave other more complex tests to external
tools).
----------------
H. S. Teoh:
I think the compiler should be able to tell, at least for the
simplest
cases, whether something will definitely stop recursing.
Whiley language (http://whiley.org/ ) is able to do this, with
the "loop variant" you write.
----------------
deadalnix:
2) By alloca();
it is @system
I'd like to use something like alloca (or much better something
similar to the variable-length stack-allocated
partially-library-defined arrays of C++14/C++17) even in @safe
code (but not in stack-constrained code we were discussing here).
We should have a page reserved at the end of the stack so we can
throw when reaching it. The compiler can ensure we don't bypass
it in case 1.
OK.
----------------
Ola Fosheim Grøstad:
A compromise would be to inject runtime checks to see if there
is
sufficient stack space whenever you move the stack pointer
Run-time tests in debug mode seem useful.
Bye,
bearophile
