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
