On Wednesday, 31 May 2017 at 23:53:11 UTC, Steven Schveighoffer
wrote:
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.
Because assuming the worst is a sane default.
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.
True, it might have already corrupted other things; but that is
no argument for allowing it to continue to potentially corrupt
even more.
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.
AFAIK the orderly shutdown is not guaranteed to be done in
release mode and I would welcome for thrown errors in release
mode to simply kill the process immediately.
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;"
Yes, precisely.
I state: "you have to assume that the index *being* out of bounds
is itself the *result* of *already occurred* data corruption;"
You state: "that preventing *attempted* memory corruption must
mean there *is* memory corruption"
You state that I claim the memory corruption must definitely have
occurred, while in contrast I state that one has to *assume* that
is has occurred. *Not* the same.
It's not the runtime's job to determine that the cause of an
out-of-bounds access could be memory corruption.
That was the job of whoever wrote the runtime, yes.
It's job is to prevent the current attempt.
That is one of its jobs. The other is to terminate when it
detects potential memory corruptions the programmer has not
ensured are not.
The problem I have is that throwing an Error itself corrupts
the program, and makes it unusable.
Because the programmer has not done the steps to ensure the
runtime that memory has not been corrupted, that is the only sane
choice I see.
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.
And anyone using wrapper implicitly promises that a wrong index
cannot be the result of memory corruption, which can definitely
be a sane choice for a lot of use cases, but not as the default
for the basic building block in the language.
