Bad array indexing is considered deadly

Walter Bright via Digitalmars-d digitalmars-d at puremagic.com
Wed May 31 18:05:42 PDT 2017


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.


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


> What are your thoughts?

Track down where the bad index is coming from and fix it.

-----------

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

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.

-----------

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.

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.

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.


More information about the Digitalmars-d mailing list