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
