Null references redux

Jesse Phillips jessekphillips at gmail.com
Sun Sep 27 09:47:51 PDT 2009


On Sun, 27 Sep 2009 10:10:19 -0400, Nick Sabalausky wrote:

> "Walter Bright" <newshound1 at digitalmars.com> wrote in message
> news:h9n3k5$2eu9$1 at digitalmars.com...
>> 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.
> 
> He keeps saying "safe", and every time he does you turn it into "memory
> safe". If he meant "memory safe" he probably would have said something
> like "memory safe". He already made it perfectly clear he's talking
> about crashes, so continuing to put the words "memory safe" into his
> mouth doesn't help the discussion.

The thing is that memory safety is the only safety with code. In Walter's 
examples he very clearly showed that a crash is not unsafe, but operating 
with incorrect values is. He has pointed out that if initialization is 
enforced, whether with a default or by coder, there is a good chance it 
will be initialized to the wrong value.

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.



More information about the Digitalmars-d mailing list