"Walter Bright" <[email protected]> wrote in message news:[email protected]... > 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?
