Bad array indexing is considered deadly

John Colvin via Digitalmars-d digitalmars-d at puremagic.com
Wed May 31 17:37:12 PDT 2017


On Wednesday, 31 May 2017 at 13:04:52 UTC, Steven Schveighoffer 
wrote:
> I have discovered an annoyance in using vibe.d instead of 
> another web framework. Simple errors in indexing crash the 
> entire application.
>
> For example:
>
> int[3] arr;
> arr[3] = 5;
>
> Compare this to, let's say, a malformed unicode string 
> (exception), malformed JSON data (exception), file not found 
> (exception), etc.
>
> Technically this is a programming error, and a bug. But memory 
> hasn't actually been corrupted. The system properly stopped me 
> from corrupting memory. But my reward is that even though this 
> fiber threw an Error, and I get an error message in the log 
> showing me the bug, the web server itself is now out of 
> commission. No other pages can be served. This is like the 
> equivalent of having a guard rail on a road not only stop you 
> from going off the cliff but proactively disable your car 
> afterwards to prevent you from more harm.
>
> 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. And vibe.d has no choice. 
> There is no guarantee the stack is properly unwound, so it has 
> to accept the characterization of this is a program-ending 
> error by the D runtime.
>
> I am considering writing a set of array wrappers that throw 
> exceptions when trying to access out of bounds elements. This 
> comes with its own set of problems, but at least the web server 
> should continue to run.
>
> What are your thoughts? Have you run into this? If so, how did 
> you solve it?
>
> -Steve

What things are considered unrecoverable errors or not is 
debatable, but in the end I think the whole things can be seen 
from the perspective of a fundamental problem of systems where 
multiple operations must be able to progress successfully* 
independently of each other. All operations (a.k.a. processes, 
fibers, or function calls within fibers, or whatever granularity 
you choose) that modify shared state (could be external to the 
fiber, the thread, the process, the machine, could be 
"real-world") must somehow maintain some consistency with other 
operations that come before, are interleaved, simultaneous or 
after.

The way I see it is that you have two choices: reason more 
explicitly about the relationship between different operations 
and carefully catch only the mishaps that you know (or are 
prepared to risk) don't ruin the consistent picture between 
operations OR remove the need for consistency. A lot of the 
latter makes the former easier.

IIRC this is what deadalnix has talked about as one of the big 
wins of php in practice, the separation of state between requests 
means that things can mess up locally without having to worry 
about wider consequences except in the specific cases where 
things are shared; I.e. the set of things that must be maintained 
consistent are opt-in, as opposed to opt-out in care-free use of 
the vibe-d model.

* "progress successfully" is itself a tricky idea.

P.S. Sometimes I do feel D is a bit eager on the self-destruct 
switch, but I think the solution is to rise to the challenge of 
making better software, not to be more blasé about pretending to 
know how to recover from unknown logic errors (exposed by 
unexpected input).


More information about the Digitalmars-d mailing list