On 5/31/17 7:13 PM, Moritz Maxeiner wrote:
On Wednesday, 31 May 2017 at 22:47:38 UTC, Steven Schveighoffer wrote:
Again, there has not been memory corruption.
Again, the runtime *cannot* know that and hence you *cannot* claim that.
It sees an index out of bounds and it *cannot* reason about whether a
memory corruption has already occurred or not, which means it *must
assume* the worst case (it must *assume* there was).
Yes, it cannot know at any point whether or not a memory corruption has
occurred. However, it has a lever to pull to say "your program cannot
continue, and you have no choice." It chooses to pull this lever on any
attempt of out of bounds access of an array, regardless of the reason
why that is happening. The chances that a memory corruption is the cause
is so low, and it doesn't matter even if it is. The program may already
have messed up everything by that point. In fact, the current behavior
of printing the Error message and doing an orderly shutdown is pretty
risky anyway if we think this is a memory corruption.
There are almost no other environmentally caused errors that cause this
lever to be pulled. It doesn't make a whole lot of sense that it is.
There is a confusion rampant in this thread that preventing
*attempted* memory corruption must mean there *is* memory corruption.
No, please no. Nobody has written that in the entire thread even once!
"you have to assume that the index *being* out of bounds is itself the
*result* of *already occurred* data corruption;"
- An index being out of bounds is an error (lowercase!).
- The runtime sees that error when the array is accessed (what you
describe as *attemped* memory corruption.
- The runtime does not know *why* the index is out of bounds
It does *not* mean that there *was* memory corruption (and again, nobody
claimed that), but the runtime cannot assume that there was not, because
that is *unsafe*.
It's not the runtime's job to determine that the cause of an
out-of-bounds access could be memory corruption. It's job is to prevent
the current attempt. Throwing an Error accomplishes this, yes, but it
also means you must shut down the program. I have no problem at all with
it preventing the corruption, nor do I have a problem with it throwing
an Error, per se. The problem I have is that throwing an Error itself
corrupts the program, and makes it unusable. Therefore, it's the wrong
tool for that job.
And I absolutely do not think that throwing an Error in this case was
the result of a careful choice deciding that memory corruption must be
or even might be the cause. I think it's this way because of the desire
to write nothrow code without having to pepper your code with try/catch
blocks.
One does not require the other.
Correct, but the runtime has to be safe in the *general* case, so it
*must* assume the worst in case of a bug.
It's easy to prove as well that throwing an Exception instead of an
Error is perfectly safe. My array wrapper is perfectly safe and does not
throw an Error on bad indexing.
-Steve
