Bad array indexing is considered deadly

[Steven Schveighoffer via Digitalmars-d]

On 5/31/17 9:05 PM, Walter Bright wrote:
> On 5/31/2017 6:04 AM, Steven Schveighoffer wrote:
>> Technically this is a programming error, and a bug. But memory hasn't
>> actually been corrupted.
>
> Since you don't know where the bad index came from, such a conclusion
> cannot be drawn.

You could say that about any error. You could say that about malformed 
unicode strings, malformed JSON data, file not found. In this mindset, 
everything should be an Error, and nothing should be recoverable.

>
>
>> This seems like a large penalty for "almost" corrupting memory. No
>> other web framework I've used crashes the entire web server for such a
>> simple programming error.
>
> Hence the endless vectors for malware insertion in those other frameworks.

No, those are due to the implementation of the interpreter. If the 
interpreter is implemented in @safe D, then you don't have those problems.

>> Compare this to, let's say, a malformed unicode string (exception),
> malformed JSON data (exception), file not found (exception), etc.
>
> That's because those are input and environmental errors, not programming
> bugs.

Not necessarily. A file name could be sourced from the program, but have 
a typo. An index could come from the environment. The library can't 
know, but makes assumptions one way or the other. Just like we assume 
you want to use the GC, these assumptions are harmful for those who need 
it to be the other way.

> There can be grey areas in classifying problems as input errors or
> programming bugs, and those will need some careful thought by the
> programmer as to which bin they fall into, and then code accordingly.
>
> Array overflows are not a grey area, however. They are always
> programming bugs.

Of course, programming bugs cause all kinds of Errors and Exceptions 
alike. Environmental bugs can cause Array overflows.

I can detail exactly what happened in my code -- I am accepting dates 
from a given week from a web request. One of the dates fell outside the 
week, and so tried to access a 7 element array with index 9. Nothing 
corrupted memory, but the runtime corrupted my entire process, forcing a 
shutdown.

With an exception thrown, I still see the programming error, I still can 
fix it, and other web pages can still continue to be served.

> This topic comes up regularly in this forum - the idea that a program
> that entered an unknown, undefined state is actually ok and can continue
> executing. Maybe that's fine on a system (such as a gaming console)
> where nobody cares if it goes off the deep end and it is not connected
> to the internet so it cannot propagate malware infections.

In fact, it did not enter such a state. The runtime successfully 
*prevented* such a state. And then instantaneously ruined the state by 
unwinding the stack without

> Otherwise, while it's hard to write invulnerable programs, it is another
> thing entirely to endorse vulnerabilities. I cannot endorse such
> practices, nor can I endorse vibe.d if it is coded to continue running
> after entering an undefined state.

It's not. And it can't be. What I have to do is re-engineer the contract 
between myself and arrays. The only way to do that is to not use builtin 
arrays. That's the part that sucks. My code will be perfectly safe, and 
not ever experience corruption. It's just a bit ugly.

> A corollary is the idea that one creates reliable systems by writing
> programs that can continue executing after corruption. This is another
> fallacious concept. Reliable systems are ones that have independent
> components that can take over if some part of them fails. Shared memory
> is not independence.

That is not what is happening here. I'm avoiding corruption so I don't 
have to crash.

-Steve