On 5/31/17 3:17 PM, Moritz Maxeiner wrote:
On Wednesday, 31 May 2017 at 13:04:52 UTC, Steven Schveighoffer wrote:
[...]
What are your thoughts? Have you run into this? If so, how did you
solve it?
It is not that accessing the array out of bounds *leading* to data
corruption that is the issue here, but that in general you have to
assume that the index *being* out of bounds is itself the *result* of
*already occurred* data corruption;
To be blunt, no this is completely wrong. Memory corruption *already
having happened* can cause any number of errors. The point of bounds
checking is to prevent memory corruption in the first place. I could
memory corrupt the length of the array also (assuming a dynamic array),
and bounds checking merrily does nothing to stop further memory corruption.
and if data corruption occurred for
the index, you *cannot* assume that *only* the index has been affected.
The runtime cannot simply assume the index being out of bounds is not
the result of already occurred data corruption, because that is
inherently unsafe, so it *must* terminate asap as the default.
The runtime should not assume that crashing the whole program is
necessary when an integer is out of range. Preventing actual corruption,
yes that is good. But an Exception would have done the job just fine.
But that ship, as I said elsewhere, has sailed. We can't change it to
Exception now, as that would break just about all nothrow code in existence.
So in your specific use case I would say use a wrapper. This is one of
the reasons why I am working on my own library for data structures (libds).
That is my conclusion too. Is your library in a usable state? Perhaps we
should not repeat efforts, though I wasn't planning on making a robust
public library for it :)
-Steve
