Bad array indexing is considered deadly

[Steven Schveighoffer via Digitalmars-d]

On 6/1/17 2:29 PM, Walter Bright wrote:
> For your date case, the date was not validated, and was fed into an
> array, where the invalid date overflowed the array bounds. The program
> was relying on the array bounds checking to validate the data.

I think it's important to state that no, I wasn't relying on array 
bounds checks to validate the data. I should be validating the data (and 
am now). What I had was a bug in my program.

What I have been saying is that in this framework, designed the way it 
is, there is no good reason to crash the entire process for such a bug. 
There are clear delineations of when the bug is in the "user code" 
section of vibe.d (i.e. the code in your project) and when it is in 
"system code" (i.e. the vibe.d framework). I want the "system code" 
section to continue to function when an out of bounds error happens in 
"user code", to give feedback to the user that no, this didn't work, 
there was an internal error.

Other frameworks and languages don't have this issue. An out of range 
error in PHP doesn't crash apache. Similarly, a segfault in a program 
doesn't crash the OS. This is the way I view the layer between vibe.d 
framework and the code that handles requests. I get that the memory is 
shared, and there's a greater risk of corruption affecting the 
framework. The right answer is to physically separate the processes, and 
at some point, maybe vibe can move in that direction (I outlined what I 
considered a good setup in another post). But a more logical separation 
is still possible by requiring for instance that all request handlers 
are @safe. Even in that case, crashing the *fiber* and not the entire 
process is still preferable in cases where the input isn't properly 
validated. Specifically, I'm talking about out-of-bounds failures, and 
not general asserts.

This is why I'm still moving forward with making my arrays throw 
Exceptions for out-of-bounds issues (and will publish the library to do 
so in case anyone else feels the same way).

> 2. Array bounds checking can be turned off by a compiler switch. Program
> data validation should not be silently disabled in such an unexpected
> manner.

Most of your points are based on the assumption that this was a design 
decision, so they aren't applicable, but on this point I wanted to say:

IMO, anything that's on the Internet should never have array bounds 
checking turned off. The risk is too great.

-Steve