Bad array indexing is considered deadly

[Moritz Maxeiner via Digitalmars-d]

On Wednesday, 31 May 2017 at 21:00:43 UTC, Steven Schveighoffer 
wrote:
> 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.

I disagree.

> Memory corruption *already having happened* can cause any 
> number of errors.

Correct, of which out of bounds array is *one*.

> The point of bounds checking is to prevent memory corruption in 
> the first place.

That is *one* of the purposes. The other is to abort in case of 
already occurred memory corruption.

> 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.

Yes, that is one case against out of bounds checks do not help; 
but that changes nothing for the case we were talking about.

>
> The runtime should not assume that crashing the whole program 
> is necessary when an integer is out of range.

Without *any* other information, I think it should.

> Preventing actual corruption, yes that is good. But an 
> Exception would have done the job just fine.

If it were only about further memory corruption, yes, but as I 
said, my argument about preexisting corruption remains.

>
> 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.

Sure.

>
>> 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?

Well, since I really needed only a single data structure at the 
time, it only contains a binary heap so far, but I believe it to 
be usable. I intend to add a dynamic array implementation next.

> Perhaps we should not repeat efforts, though I wasn't planning 
> on making a robust public library for it :)

Well, you can take a look at the binary heap implementation[1] 
and decide if that a style you are interested in, but it does 
currently use errors for things such as removing an element when 
the heap is empty; I am not sure there, what I intend to do here, 
but I might make it configurable via the Conf template parameter 
in a design-by-introspection style.

[1] https://github.com/Calrama/libds