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.

On 7/25/2013 8:39 PM, H. S. Teoh wrote:
> How would a D program recover from stack overflow?

The program doesn't. In a safe system, there'd be a backup in case the main program failed (which it inevitably will).

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

That works until you have more than one thread.

On 7/25/2013 7:19 PM, bearophile wrote:
> You don't want a stack overflow in the code that controls your car brakes (this is not a
> totally invented example).

Sadly, it isn't:

http://www.forbes.com/sites/andygreenberg/2013/07/24/hackers-reveal-nasty-new-car-attacks-with-me-behind-the-wheel-video/

Software controlled brakes with no override? Madness!

On Friday, 26 July 2013 at 05:13:37 UTC, Walter Bright wrote:
> On 7/25/2013 7:19 PM, bearophile wrote:
>> You don't want a stack overflow in the code that controls your car brakes (this is not a
>> totally invented example).
>
> Sadly, it isn't:
>
> http://www.forbes.com/sites/andygreenberg/2013/07/24/hackers-reveal-nasty-new-car-attacks-with-me-behind-the-wheel-video/
>
> Software controlled brakes with no override? Madness!

Only death statistics for a sufficiently long usage period could tell whether software + override is safer than purely software. Note that software + override is significantly more complex, which means a decrease in reliability of the system in whole.

On Friday, 26 July 2013 at 05:13:37 UTC, Walter Bright wrote:
> On 7/25/2013 7:19 PM, bearophile wrote:
>> You don't want a stack overflow in the code that controls your car brakes (this is not a
>> totally invented example).
>
> Sadly, it isn't:
>
> http://www.forbes.com/sites/andygreenberg/2013/07/24/hackers-reveal-nasty-new-car-attacks-with-me-behind-the-wheel-video/
>
> Software controlled brakes with no override? Madness!

I presume you always had some override system with anything critical at Boeing?


P.S. I don't suppose you happened to work with Bogdan Hnat there? It's a long shot as I think you would have left before he started.

On Friday, 26 July 2013 at 02:39:15 UTC, Walter Bright wrote:
> 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.

So very true, this is a rule number one for designing high availability systems. One must assume that any single program is always doomed to fail and focus on designing whole system that will not. Duplication, various heartbeat watchdogs and fast recovery times for processes are key here.

Also nothing that is powered from the same power source can't be considered fail-safe. ;)

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

On Thursday, 25 July 2013 at 18:23:19 UTC, Xinok wrote:
> Once in a while, a thread pops up in the newsgroups pitting D against some other language. More often than not, these comparisons are flawed, non-encompassing, and uninformative. Most recently with the article comparing D with Go and Rust, the community pointed out a few flaws involving a late addition of one of the D compilers, build configurations (-noboundscheck?), and the random number generator used.
>
> Then when I think about how web browsers are compared, there are conventional measures and standard benchmarking tools (e.g. sunspider). They measure performance for javascript, rendering, HTML5, etc. They also measure startup times (hot/cold boot), memory usage, etc. Finally, there are feature comparisons, such as what HTML5 features each browser supports.
>
> These are the type of comparisons I'd like to see with programming languages. For starters, there should be standard "challenges" (algorithms and such) implemented in each language designed to measure various aspects of the language, such as sorting, number crunching, and string processing. However, rather than leave it to a single individual to implement the algorithm in several different languages, it should be left to the community to collaborate and produce an "ideal" implementation of the algorithm in their language. We could analyze factors other than performance, such as the ease of implementation (how many lines? does it use safe/unsafe features? Was it optimized using unsafe / difficult features?).
>
>
> What can we do about it? I propose we come together as a community, design challenges that are actually relevant and informative, and release the first implementations in D. Then we let the battle commence and invite other communities to contribute their own implementations in other languages. I think we should give it a try; start off small with just a few moderate challenges (not too simple or complex) and see where it goes from there.

I have learned to be wary of comparisons like that. Any language that is sponsored or owned by a big company always "outperforms" other languages, and at the end of the day they only want to bind you to their products, no matter how "open source" they are. You can basically proof whatever you want. Most of the discussions I have had don't revolve around whether the language is good or not, it's about what people have heard/read, "Who uses it?", "I've heard ..." "Someone said ..." I once told a guy about D. He said "Ah, D, old-fashioned!" and he showed me a link that said "C# has a more modern feature ... bla bla". How ... scientific!

On Fri, Jul 26, 2013 at 03:18:03PM +0200, Chris wrote: [...]
> I have learned to be wary of comparisons like that. Any language that is sponsored or owned by a big company always "outperforms" other languages, and at the end of the day they only want to bind you to their products, no matter how "open source" they are.

+1.

I'm skeptical of attempts to reduce everything down a single number or three, that can serve as a basis for numerical (or hand-waving) comparisons. As if programming languages were that simple that one could place them neatly on what is effectively a scale of 1 to 10!


> You can basically proof whatever you want. Most of the discussions I have had don't revolve around whether the language is good or not, it's about what people have heard/read, "Who uses it?", "I've heard ..." "Someone said ..." I once told a guy about D. He said "Ah, D, old-fashioned!" and he showed me a link that said "C# has a more modern feature ... bla bla". How ... scientific!

I get that a lot from Java fanboys. They make bold-sounding statements like "Java is the future!", "Java is the best!", "D sucks, nobody uses it!", "Java will get you a job easily!". But I've yet to hear some factual evidence to back up these claims. Well, maybe except the last one -- it's true that given Java's popularity, it has a high chance of landing you a job. But the point is, just because it will land you a job doesn't necessarily make it a *good* language, it merely shows that it's a *popular* one.  Popular doesn't imply good.


T

-- 
"I'm running Windows '98."
"Yes."
"My computer isn't working now."
"Yes, you already said that."
-- User-Friendly

On Friday, 26 July 2013 at 14:05:12 UTC, H. S. Teoh wrote:
> On Fri, Jul 26, 2013 at 03:18:03PM +0200, Chris wrote:
> [...]
>> I have learned to be wary of comparisons like that. Any language
>> that is sponsored or owned by a big company always "outperforms"
>> other languages, and at the end of the day they only want to bind
>> you to their products, no matter how "open source" they are.
>
> +1.
>
> I'm skeptical of attempts to reduce everything down a single number or
> three, that can serve as a basis for numerical (or hand-waving)
> comparisons. As if programming languages were that simple that one could
> place them neatly on what is effectively a scale of 1 to 10!
>
>
>> You can basically proof whatever you want. Most of the discussions I
>> have had don't revolve around whether the language is good or not,
>> it's about what people have heard/read, "Who uses it?", "I've heard
>> ..." "Someone said ..." I once told a guy about D. He said "Ah, D,
>> old-fashioned!" and he showed me a link that said "C# has a more
>> modern feature ... bla bla". How ... scientific!
>
> I get that a lot from Java fanboys. They make bold-sounding statements
> like "Java is the future!", "Java is the best!", "D sucks, nobody uses
> it!", "Java will get you a job easily!". But I've yet to hear some
> factual evidence to back up these claims. Well, maybe except the last
> one -- it's true that given Java's popularity, it has a high chance of
> landing you a job. But the point is, just because it will land you a job
> doesn't necessarily make it a *good* language, it merely shows that it's
> a *popular* one.  Popular doesn't imply good.
>
>
> T

Yep. And I think that someone who knows D or any other language that is not mainstream is seriously into programming. If you know Java or Python, what does that mean? That you are a good programmer? If you know how to program, you can learn any language you want. The question is usually not "I wonder if I can write the program." the question is usally "I know what I have to do. But how do I do it in D, C, Java ...?" It's the how, not the if.