Making alloca more safe

[bearophile]

I am sorry for having mixed global reliability of a system with the discussion about non nullable class references. It's my fault. Those are two very different topics, as Walter says. Here I give few comments, but please try to keep the two things separated. If that's not possible, feel free to ignore this post...

Adam D. Ruppe:

>Would you have preferred it to just randomly do its own thing and potentially end up landing on people?<

Your mind is now working in terms of 0/1. But that's not how most things in the universe work. A guide system designed with different design principles may have guided it safely, with a small error in the trajectory, that may be fixed later in orbit.


>Even expensive, important pieces of equipment can always be replaced.<

The scientific equipment it was carrying is lost, no one has replaced it so far. It was very complex.


>What would you have it do? Carry on in the error state, doing Lord knows what? That's clearly unsafe.<

My idea was to have a type system that avoids such errors :-)


>Hospitals know their medical machines might screw up, so they keep a nurse on duty at all times who can handle the situation - restart the failed machine, or bring in a replacement before it kills someone.<

This is not how things are.


>I wouldn't say safer, though I will concede that it is easier to debug.<

A program that doesn't break in the middle of its run is safer if you have to use it for something more important than a video game :-)

-------------------

Walter Bright:

>Computers cannot know whether a problem is "small" or not.<

The system designer can explain to the computer what "small" means in the specific situation.


>This is how you make reliable systems:<

I'm a biologist, and I like biology-inspired designs. There is not just 1 way to design reliable systems that must work in the real world. Biology shows several other ways. Today people are starting to copy nature in such regard too, for example designing swarms of very tiny robots that are able to perform a task even if some tiny robot gets damaged or struck, etc.


>Pretending a program hasn't failed when it has, and just "soldiering on", is completely unacceptable behavior in a system that must be reliable.<

Well, it's often a matter of degree. On Windows I have amateur-level image editing programs that sometimes have a bug, and one of their windows "dies" or gets struck. I can usually keep working a little with that program and then save the work, and then restart the program.


>The Ariane 5 had a backup system which was engaged, but the backup system had the same software in it, so failed in the same way. That is not how you make reliable systems.<

I have read enough about that case. I agree that it was badly designed. But in our universe there is more than 1 true way to design a reliable system.


>You're using two different definitions of the word "safe". Program safety is about not corrupting memory. System safety (i.e. reliability) is a completely different thing.<

I'd like my programs to be safer in the system safety way.


>If you've got a system that relies on the software continuing to function after an unexpected null seg fault, you have a VERY BADLY DESIGNED and COMPLETELY UNSAFE system. I really cannot emphasize this enough.<

My idea was to introduce ways to avoid nulls in the first place.


>by aviation companies who take this issue extremely seriously.<

There are wonderful birds (alatross) that keep flying across thousand of kilometers (and singing&loving to each other and laying large eggs) after 50+ years:
http://news.nationalgeographic.com/news/2003/04/0417_030417_oldestbird.html
They are biological systems way more complex that a modern aeroplane, they are made of subsystems (like cells in their brain) that are not very reliable. They use a different design strategy to be so reliable.

Sorry for mixing two so unrelated topics, my second stupid mistake of today.

Bye,
bearophile