Null references redux

[Walter Bright]

Jason House wrote:
>> Also, by "safe" I presume you mean "memory safe" which means free
>> of memory corruption. Null pointer exceptions are memory safe. A
>> null pointer could be caused by memory corruption, but it cannot
>> *cause* memory corruption.
> 
> I reject this argument too :( To me, code isn't safe if it crashes.

Well, we can't discuss this if we cannot agree on terms. The 
conventional definition of memory safe means no memory corruption. A 
null pointer dereference is not memory corruption. You can call it 
something else, but if you call it "unsafe" then people will 
misunderstand you.


> Did Boeing avoid checking for fault modes that were easily and
> reliably detectable? It seems stupid to argue that it's ok for an
> altimeter can send bogus data as long as it's easy to detect. All you
> have to do is turn off autopilot. Who cares, right?

Errors in incorrectly initialized data are not easily and reliably 
detectable. A null pointer, on the other hand, *is* reliably detectable 
by the hardware.

Boeing's philosophy is that if the airplane cannot tolerate a particular 
system failing abruptly and completely, then the design is faulty. 
That's also the FAA regulations. Safety is achieved NOT by designing 
systems that cannot fail, but by designing systems that can survive failure.

In particular, if the airplane cannot handle turning off the autopilot, 
it will be rejected by both Boeing and the FAA. Name any single part or 
system on a Boeing airliner, and if it vanishes abruptly in a puff of 
smoke, the airliner will survive it.

There is no "the autopilot is receiving corrupted data, but what the 
hell, we'll keep it turned on anyway". It's inconceivable.

The only reasonable thing a program can do if it discovers it is in an 
unknown state is to stop immediately. The only reasonable way to use a 
program is to be able to tolerate its complete failure.


> Why should I use D for production code if it's designed to segfault?
> Software isn't used for important things like autopilot, controlling
> the brakes in my car, or dispensing medicine in hospitals. There's no
> problem allowing that stuff to crash. You can always recover the core
> file, and it's always trivial to reproduce the scenario...

It's not designed to segfault. It's designed to expose errors, not hide 
them. The system that uses the autopilot is designed to survive total 
failure of the autopilot. The same for your brakes in your car (ever 
wonder why there are dual brake systems, and if your power assist fails 
you can still use the brakes?). I don't know how the ABS works, but I 
would bet you plenty that if the computer controlling it fails, the 
brakes will still function. And you bet your life (literally) that if a 
computer dispensing radiation or medicine into your body better stop 
immediately if it detects it is in an unknown state.

Do you *really* want the radiation machine to continue operating if it 
has self-detected a program bug? Do you really want to BET YOUR LIFE 
that the software in it is perfect? Do you think that requiring the 
software be literally perfect is a reasonable, achievable, and safe 
requirement?

I don't. Not for a minute. And NOTHING Boeing designs relies on 
perfection for safety, either. In fact, the opposite is true, the 
designs are all based on "what if this fails?" If the answer is "people 
die" then the engineers are sent back to the trenches.

Hospitals are way, way behind on this approach. Even adding simple 
checklists (pilots starting using them 70 years ago) have reduced 
accidental deaths in hospitals by 30%, a staggering improvement.

> Mix in other things like malfunctioning debug data, and I wonder why
> I even use D.

The debug data is a serious problem, and I think I've got it corrected now.