A proper language comparison...

[H. S. Teoh]

On Thu, Jul 25, 2013 at 07:39:15PM -0700, Walter Bright wrote:
> 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).

And how does stack overflow differ from heap overflow? Either way, your
program can't continue normal execution (e.g., issue a command to engage
all brakes).


> 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.

How would a D program recover from stack overflow?


[...]
> >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.
[...]

Isn't it possible to allocate the stack at the far end of the program's
address space, so that it can grow as needed?

Apparently Linux doesn't do that, though. Or at least, not by default.

I can sorta guess why: allowing the stack to grow arbitrarily large has
the possibility of a buggy program consuming all memory resources before
getting terminated by running out of memory (say the program has an
infinite loop allocating huge gobs of stack space per iteration). On a
moderately-sized stack, the program will get killed by stack overflow
before it can do much harm; a program with unconstrained stack size may
well take down the system with it by eating up all memory (both RAM
*and* swap) before it crashes.  The system will likely grind to a halt
as it starts thrashing from lack of RAM, and then overflowing the swap,
and basically make a mess of everything before the OS finally kills off
the buggy program (assuming that the OS can recover, of course). Not
unlike a fork bomb in some ways.  :-P


T

-- 
I am Ohm of Borg. Resistance is voltage over current.