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