A proper language comparison...

[Walter Bright]

On 7/25/2013 7:19 PM, bearophile wrote:
> If you allocate too much data on the stack this could cause stack overflow. As
> you say a stack overflow is memory safe, but if your program is doing something
> important, a sudden crash could be regarded as dangerous for the user. You don't
> want a stack overflow in the code that controls your car brakes (this is not a
> totally invented example).

If you are writing a program that, if it fails will cause your car to crash, 
then you are a bad engineer and you need to report to the woodshed.

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.

> Having variable-sized stack-allocated arrays encourages you to put more data on
> the stack, increasing the risk of stack overflows.
>
> On the other hand, if you only have fixed-sized stack-allocated arrays, you
> could allocate a fixed size array on the stack and then use only part of it.
> This waste of stack space increases the probability of stack overflow. A
> variable-sized stack-allocated array allows you to waste no stack space, and
> avoid those stack overallocations.

On the other hand, fixed size stack allocations are more predictable and hence a 
stack overflow is more likely to be detected during testing.


> If you are using a segmented stack as Rust, stack overflows become less probable
> (it becomes more like a malloc failure), because the stack is able to become
> very large when needed. I think Rust needs that elastic stack because in such
> language it's easy to allocate all kind of stuff on the stack (unlike in D).

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.

(Segmented stacks are also a performance problem, and don't interact well with 
compiled C code.)