Bad array indexing is considered deadly
Moritz Maxeiner via Digitalmars-d
digitalmars-d at puremagic.com
Wed May 31 17:41:52 PDT 2017
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.
More information about the Digitalmars-d
mailing list