Bad array indexing is considered deadly

[Arafel via Digitalmars-d]

On 06/02/2017 01:26 PM, Steven Schveighoffer wrote:
> 
> If only that is what happened, I would not have started this thread!
> 
> In any case, the way forward is clear -- create containers that don't 
> throw Error, and make them easy to use.
> 
> I think I will actually publish them, because it's a very useful thing 
> to have. You can validate your input all you want, but if you have a 
> program bug, or there is something you didn't consider, then the entire 
> server isn't crashed because of it. I *like* the bounds checking, I 
> don't have to translate back to the input what it will mean for every 
> array access in the function -- the simple check is enough.
> 
> Still good to have it auto-restart, which I will also do. But having 
> some sort of feedback to the client, and an attempt to continue on with 
> other unrelated requests is preferable.
> 
> -Steve


Hi,

I think that most people agree that an out-of-bounds access is a bug 
that needs to be fixed, this shouldn't be an acceptable way of running 
the program.

The question here seems to be what to do *in the meanwhile*, and here is 
the problem. I can understand the position that from a theoretical point 
of view the process is already unsafe at this point, and that the best 
option is to stop (and restart if needed).

But, in the real world if I've got a (web)server that has proper 
isolation, I'd much rather have a server that sends back a 500 [error 
message] for the buggy page and keeps working otherwise, than one that 
is killed and has to be restarted every time a buggy page is asked.

Think that it can be a multithreaded server, and that other ongoing (and 
safe!) tasks might be affected, and that safe restart, even when 
available, often has a performance hit.

I agree that one (perhaps even the proper) way to get this is through 
process isolation, but this doesn't mean that the language shouldn't 
allow it if needed and explicitly required. There are ways for the 
programmer to explicitly disable most other security features 
(__gshared, casting away shared and immutable, @trusted code, etc.) so 
why not this one?

Perhaps an intermediate solution would be to offer a compiler switch 
that allows Errors to be safely caught (that is, they behave as 
exceptions). As far as I understand from reading this thread, that's 
already the case in debug builds, so it cannot be that bad practice, but 
it would be nice to have a mode that it's otherwise "release", only with 
this feature turned on.

Even better would be to turn on this behaviour on a per-function basis 
(say @throwErrors). Although perhaps that'd be promoting this behaviour 
a bit too much...

Anyway, just 2¢ from a half-newbie (okay, still full-newbie :) )