On 01.06.2017 01:13, Moritz Maxeiner wrote:
On Wednesday, 31 May 2017 at 22:47:38 UTC, Steven Schveighoffer wrote:
Again, there has not been memory corruption.
Again, the runtime *cannot* know that and hence you *cannot* claim that.
It sees an index out of bounds and it *cannot* reason about whether a
memory corruption has already occurred or not, which means it *must
assume* the worst case (it must *assume* there was).
There is a confusion rampant in this thread that preventing
*attempted* memory corruption must mean there *is* memory corruption.
No, please no. Nobody has written that in the entire thread even once!
- An index being out of bounds is an error (lowercase!).
- The runtime sees that error when the array is accessed (what you
describe as *attemped* memory corruption.
- The runtime does not know *why* the index is out of bounds
It does *not* mean that there *was* memory corruption (and again, nobody
claimed that), but the runtime cannot assume that there was not, because
that is *unsafe*.
...
No, it is perfectly safe, because the language does not guarantee any
specific behavior in case memory is corrupted. Therefore the language
can /always/ assume that there is no memory corruption.
One does not require the other.
Correct, but the runtime has to be safe in the *general* case, so it
*must* assume the worst in case of a bug.
Software has bugs. The runtime has no business claiming that the scope
of any particular bug is the entire service. The practical outcomes of
this design are just silly. Data is lost, services go down, etc. When in
doubt, the software should just do what the programmer has written. It
is not always correct, but it is the best available proxy of the
desirable behavior.
