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