On 7/26/2013 10:25 AM, deadalnix wrote:
> You emphasis it quite well, and that is certainly true for a car, a plane, or
> anything potentially dangerous.
>
> Different tradeoff apply when you talk about a video game, a media player or and
> IRC client.

Of course.

There is a cost of failure, though, to things like video games and media players. Annoying your customers. I've dumped using many media players because of their tendency to freeze up. I like to set my music on in the morning and run it all day. Having to regularly restart it means "abandon it and try a different one."

My current media player freezes about once every couple weeks. It's infrequent enough to be tolerable. The Ubuntu one dies about once an hour. I gave up on that long ago.

On 7/26/2013 12:30 PM, Chris Cain wrote:
> I wouldn't recommend turning the ignition off. Most cars lose power steering in
> that situation which is can be just as bad as or worse than losing brakes.

The power steering is driven by a belt connected to the crankshaft. You won't lose power steering with the ignition off if the engine is turning.

But you need to be careful not to engage the steering lock. That would be a big problem.

And also, I suggest this as a last resort if your other braking systems all failed.

> Most cars (including automatics) allow you to manually switch to lower gears
> which will also slow you down.

I have little experience with automatics.

On Fri, Jul 26, 2013 at 08:58:27PM +0200, Tofu Ninja wrote:
> On Friday, 26 July 2013 at 18:46:06 UTC, H. S. Teoh wrote:
> >...for example, to judge Java on the basis of how well one could write an OS in it
> 
> http://jos.sourceforge.net/

Wait... that's an OS that runs in a JVM? Wouldn't it need another OS to act as host?  My mind is boggled...


T

-- 
Always remember that you are unique. Just like everybody else. -- despair.com

On Fri, Jul 26, 2013 at 01:58:33PM -0700, Walter Bright wrote:
> On 7/26/2013 12:30 PM, Chris Cain wrote:
> >I wouldn't recommend turning the ignition off. Most cars lose power steering in that situation which is can be just as bad as or worse than losing brakes.
> 
> The power steering is driven by a belt connected to the crankshaft. You won't lose power steering with the ignition off if the engine is turning.
> 
> But you need to be careful not to engage the steering lock. That would be a big problem.
> 
> And also, I suggest this as a last resort if your other braking systems all failed.
> 
> >Most cars (including automatics) allow you to manually switch to lower gears which will also slow you down.
> 
> I have little experience with automatics.

I think most automatics lock the steering wheel upon power off (probably as some kind of safety guard, maybe against inadvertent damage by some parts that expect power to be running when the wheel is turned?).

I also use manual downshifting on my car (auto transmission) to force it to slow down -- e.g., down a hill, when the automatic transmission will often blindly shift to a high gear and you'll find yourself having to burn up much of your brakes to keep the speed under control. My car has a button that locks the maximum gear to 3rd, which is useful for keeping within city street limits when going downhill. It also has gear positions to force a switch to 2nd or 1st gear, though I rarely use those since at lower speeds there's generally no need to bother with them. In an emergency situation, forcing it to 1st gear would help reduce the speed. (But it does take a few seconds before the auto transmission kicks in to effect the switch -- and a few extra seconds at high speed can be too long in an emergency situation.)

I think the one time when forcing 1st gear proved useful was when I had to drive downhill after a heavy snowstorm -- you do *not* want to go any higher in that situation otherwise you could easily lose friction and slide down to a nasty crunch at the bottom. (Well, the general advice is, don't drive in such conditions in the first place -- but then guys like me are often rather foolhardy. :-P)


T

-- 
2+2=4. 2*2=4. 2^2=4. Therefore, +, *, and ^ are the same operation.

On 7/26/13 12:50 PM, Walter Bright wrote:
> On 7/26/2013 5:28 AM, bearophile wrote:
>
>> 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.
>
> You can't have an undetected stack overflow if you use guard pages.

If you use guard pages AND guarantee that no object exceeds the size of the guard page.  Without the latter, you can only catch a subset (though a large subset).

Walter Bright:

> Yes, and that's why your analysis of Rust's stack usage is inadequate in demonstrating it is safer.

There I was not talking about Rust, but about more constrained systems (where maybe Rust someday will run, but it will need some changes).

In desktop PCs usually there is plenty of RAM to grow a stack for lot of time, safely. So I think Go and Rust programs have a low risk of stack overflows if you run them on normal PCs.


> You can't have an undetected stack overflow if you use guard pages.

They don't care about this much. For those high integrity systems they remove stack overflows from happening, sizing the stack with a careful static analysis, because for those software usages a stack overflow is dangerous :-) Their main problem is not detecting it, it's avoiding it. And for other systems a stack overflow can be a nuisance/problem.


> I'll add that segmented stacks are a compiler feature, not a language feature. A D compiler could support segmented stacks without changing the language, provided calling C functions still works.

I see.


> But I see no point.

I have never asked for having a segmented stack in D. But both Go and Rust developers are smart people, running code mostly on 64 bit systems, and both have designed their languages in recent years with segmented stacks. So perhaps you could go read their motivations. My guess is that Rust programs can allocate lot of stuff on the stack, and just like a heap a larger input data causes a larger stack to be used. Having an extensible stack probably avoids stack from exhausting too much easily on normal PCs. But parallelism could be another cause (that you already answered).

Bye,
bearophile

On Fri, Jul 26, 2013 at 12:54:57PM -0700, Walter Bright wrote:
> On 7/26/2013 10:25 AM, deadalnix wrote:
> >You emphasis it quite well, and that is certainly true for a car, a plane, or anything potentially dangerous.
> >
> >Different tradeoff apply when you talk about a video game, a media player or and IRC client.
> 
> Of course.
> 
> There is a cost of failure, though, to things like video games and media players. Annoying your customers. I've dumped using many media players because of their tendency to freeze up. I like to set my music on in the morning and run it all day. Having to regularly restart it means "abandon it and try a different one."

Yeah, I had that experience with my old iPod. There was no (obvious) way to control what's running, so every once in a while, some wayward app would start consuming all system resources and the music would start to skip and eventually the thing would freeze. It was very annoying, especially since there was no way to tell *what* was causing the problem. I stopped using the iPod as a music player (sigh...).

On my new Android phone, things a slightly better -- at least there's a task manager that I can use to kill off misbehaving programs or apps known to exhibit erratic behaviour, before I set up the music to play all day. That way, things are less likely to fail.


> My current media player freezes about once every couple weeks. It's infrequent enough to be tolerable. The Ubuntu one dies about once an hour. I gave up on that long ago.

That sounds pretty bad. I think my HTC phone only ever froze once since late last year when I first got it. Every couple weeks sounds almost as bad as my iPod (which I no longer use).


T

-- 
Computers are like a jungle: they have monitor lizards, rams, mice, c-moss, binary trees... and bugs.

On 7/26/2013 2:18 PM, Brad Roberts wrote:
> On 7/26/13 12:50 PM, Walter Bright wrote:
>> On 7/26/2013 5:28 AM, bearophile wrote:
>>
>>> 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.
>>
>> You can't have an undetected stack overflow if you use guard pages.
>
> If you use guard pages AND guarantee that no object exceeds the size of the
> guard page.  Without the latter, you can only catch a subset (though a large
> subset).
>

True. I've often thought it would be reasonable to restrict object sizes on the stack.

On 7/26/2013 2:42 PM, Walter Bright wrote:
> On 7/26/2013 2:18 PM, Brad Roberts wrote:
>> On 7/26/13 12:50 PM, Walter Bright wrote:
>>> On 7/26/2013 5:28 AM, bearophile wrote:
>>>
>>>> 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.
>>>
>>> You can't have an undetected stack overflow if you use guard pages.
>>
>> If you use guard pages AND guarantee that no object exceeds the size of the
>> guard page.  Without the latter, you can only catch a subset (though a large
>> subset).
>>
>
> True. I've often thought it would be reasonable to restrict object sizes on the
> stack.

No, I was wrong. False. Stack frames larger than 4K are sequentially "probed" so they'll fault on overflow.

On Friday, 26 July 2013 at 19:38:06 UTC, Walter Bright wrote:
> I am continually amazed at critical systems design in Fukushima and Deep Water Horizon that have no backups or overrides.

I hope I'm not being unfair, but my impression was that the very impressive modern safety record of air travel is at least partly down to lessons learned from some major historical catastrophes. The one that always springs to mind is the De Havilland jets breaking apart mid-flight due to metal fatigue.

The number of flights and resulting near misses surely helps to battle test safely procedures and designs. That volume of learning opportunities can't readily be matched in many other industries.

That's not to defend the examples you cite -- the holes in safety provision in both of them were pretty shocking.