Null references redux

Jeremie Pelletier jeremiep at gmail.com
Mon Sep 28 19:56:27 PDT 2009


Andrei Alexandrescu wrote:
> language_fan wrote:
>> Mon, 28 Sep 2009 15:35:07 -0400, Jesse Phillips thusly wrote:
>>
>>> language_fan Wrote:
>>>
>>>>> Now if you really want to throw some sticks into the spokes, you
>>>>> would say that if the program crashes due to a null pointer, it is
>>>>> still likely that the programmer will just initialize/set the value
>>>>> to a "default" that still isn't valid just to get the program to
>>>>> continue to run.
>>>> Why should it crash in the first place? I hate crashes. You liek them?
>>>> I can prove by structural induction that you do not like them when you
>>>> can avoid crashes with static checking.
>>> No one likes programs that crash, doesn't that mean it is an incorrect
>>> behavior though?
>>>
>>>> Have you ever used functional languages? When you develop in Haskell or
>>>> SML, how often you feel there is a good change something will be
>>>> initialized to the wrong value? Can you show some statistics that show
>>>> how unsafe this practice is?
>>> So isn't that the question? Does/can "default" (by human or machine)
>>> initialization create an incorrect state? If it does, do we continue to
>>> work as if nothing was wrong or crash? I don't know how often the
>>> initialization would be incorrect, but I don't think Walter is concerned
>>> with it's frequency, but that it is possible.
>>
>> Value types can be incorrectly initialized and nobody notices. E.g.
>>
>>   int min;
>>
>>   foreach(int value; list)
>>     if (value < min) min = value;
>>
>> Oops, you forgot to define a flag variable or initialize to int.min
> 
> You mean int.max :o).
> 
> Andrei

He just proved how enforcing initializers can still cause errors! I 
didn't even think of that one!

:o)



More information about the Digitalmars-d mailing list