Walter Bright:
As I've written before, imagining you can write a program that
cannot fail, coupled with coming up with a requirement that a
program cannot fail, is BAD ENGINEERING.
ALL COMPONENTS FAIL.
The way you make a system safe is design it so that it can
withstand failure BECAUSE THE FAILURE IS GOING TO HAPPEN. I
cannot emphasize this enough.
I agree. On the other hand in important system you usually also
try to use more reliable single components, like military-grade
resistors able to stand bigger temperature fluctuations. Safety
must be pursued at all levels. That's why in both automotive and
aeronautics for certain safety-critical routines they forbid
recursion and require a static analysis of the max stack space
the subprogram will require in all possible usages, to reduce a
lot the probability of stack overflows.
In some situations stack overflows are a security problem.
Several persons have written programs to analyse the stack usage
of Ada-SPARK programs. Ignoring the safety hazards caused by
stack overflows, and ignoring the tools to avoid them in
critical-purpose routines, is very bad engineering.
On the other hand, fixed size stack allocations are more
predictable and hence a stack overflow is more likely to be
detected during testing.
I agree. Here the interactions are not linear :-)
Segmented stacks are a great idea for 20 years ago. 64 bit code
has rendered the idea irrelevant - you can allocate 4 billion
byte stacks for each of 4 billion threads. You've got other
problems that'll happen centuries before that limit is reached.
Rust designers should comment on this :-) I am not expert enough
on this.
(Segmented stacks are also a performance problem, and don't
interact well with compiled C code.)
I don't know the current situation on this, but I think they are
trying to solve this problem in Rust, with some workaround.
Bye,
bearophile
