Making alloca more safe

[Andrei Alexandrescu]

bearophile wrote:
> Walter Bright:
> 
>> I don't want to get into another loooong thread about should
>> pointers be nullable or not,
> 
> It was a good thread with good ideas.
> 
> 
>> I just wished to point out that it was not a *safety* issue.<
> 
> A safe system is not a program that switches itself off as soon as
> there's a small problem.
> 
> One Ariane missile has self-destroyed (and destroyed an extremely
> important scientific satellite it was carrying whose mission I miss
> still) because of this silly behaviour united with the inflexibility
> of the Ada language.
> 
> A reliable system is a systems that keeps working correctly despite
> all. If this is not possible, in real life you usually want a "good
> enough" behaviour. For example, for your TAC medical machine, in
> Africa if the machine switches itself off at the minimal problem they
> force the machine to start again, because they don't have money for a
> 100% perfect fix. So for them it's better a machine that shows a slow
> and graceful degradation. That's a reliable system, something that
> looks more like your liver, that doesn't totally switch off as soon
> it has a small problem (killing you quickly).
> 
> A program that stops working in a random moment because of a null is
> not safe. (And even if you accept this, in safer languages like
> C#/Java there are null exceptions that show a stack trace. The type
> system is smart enough to remove most of those tests to improve
> performance). A safer program is a program that avoids null pointer
> exception because the type system has formally verified the program
> has no nulls.
> 
> Bye, bearophile

I think it all has to do with definitions. If you define safety as a 
yes/no property, then there can be no discussion about "safer".

The classic safety definition involves progress and preservation. If 
those are satisfied for all programs, the language is safe. All 
languages in actual use cannot satisfy progress for all programs, which 
makes the definition too restrictive. So people use more relaxed 
definitions, e.g. allow for stuck states (e.g. use of a null pointer is 
a stuck state) or work in terms of trapped vs. untrapped errors.

D's definition of safety is "no undefined behavior" which is as far as I 
can understand a tight superset of "no untrapped errors". If we go by 
that definition we can't talk about safer or less safe. You either have 
UB or don't.

That being said, I like non-null references. The problem is that as soon 
as someone tries to enumerate safety among the desirable behaviors of 
non-null references, Walter's regard for the argument completely shuts 
down, taking down with it all good arguments too.


Andrei