Bad array indexing is considered deadly

[Timon Gehr via Digitalmars-d]

On 01.06.2017 01:13, 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).
> 
>> 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!
> - 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*.
> ...

No, it is perfectly safe, because the language does not guarantee any 
specific behavior in case memory is corrupted. Therefore the language 
can /always/ assume that there is no memory corruption.

>> 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.

Software has bugs. The runtime has no business claiming that the scope 
of any particular bug is the entire service. The practical outcomes of 
this design are just silly. Data is lost, services go down, etc. When in 
doubt, the software should just do what the programmer has written. It 
is not always correct, but it is the best available proxy of the 
desirable behavior.