A proper language comparison...

[bearophile]

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