Null references redux

Nick Sabalausky a at a.a
Sun Sep 27 07:10:19 PDT 2009


"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.

> Boeing, Boeing, Boeing, Boeing, Boeing...

Straw man. No one's arguing against designing systems to survive failure, 
and no one's arguing against forcing errors to be exposed.

Your point seems to be: A good system is designed to handle a crash/failure 
without corruption, so let's allow things to crash/fail all they want.

Our point is: A good system is designed to handle a crash/failure without 
corruption, but let's also do what we can to minimize the amount of 
crashes/failures in the first place.

You're acting as if handling failures safely and minimizing failures were 
mutually exclusive.

> It's not designed to segfault. It's designed to expose errors, not hide 
> them.

Right. And some of these errors can be exposed at compile time...and you 
want to just leave them as runtime segfaults instead? And you want this 
because exposing an error at compile time somehow causes it to become a 
hidden error?





More information about the Digitalmars-d mailing list