> In some cases, bounds checking doesn't make sense, e.g. in video games running on consoles.
As if it couldn't be used to exploit and pirate the games, get extra lifes, buy in-game items without paying, automate bots...
"Many years later we asked our customers whether they wished us to provide an option to switch off these checks in the interests of efficiency on production runs. Unanimously, they urged us not to--they already knew how frequently subscript errors occur on production runs where failure to detect them could be disastrous. I note with fear and horror that even in 1980, language designers and users have not learned this lesson. In any respectable branch of engineering, failure to observe such elementary precautions would have long been against the law."
Amen! A couple of years back, I worked at a company where I helped maintain and improve a couple of programs written in C, and words cannot express how much I wished for a compiler switch to get bounds-checking, even if it was just for testing and debugging... Garbage collection/memory management was never much of a problem, but those nasty little off-by-one errors causing the program to corrupt the heap (which of course did not make it crash until a while later, so the location of the crash was usually totally unrelated to where the actual bug was located... sigh) drove me nuts!
I think most languages other than C do this in one way or another. In idiomatic C++, arrays and raw pointers are frowned upon, I am told, in Go arrays have a fixed length that is part of their type, and slices carry their length with them, of course. And languages like C#, Java, Python, ... have done this for a pretty long time.
Of all the languages used to implement desktop and server software (these days, at least), C is pretty much unique in that it makes no effort whatsoever to help the programmer avoid or uncover these errors.
And don't get me wrong, I pretty much like C, even though I do not use it very often, but if there was one thing I could change about it, it is this. Given the amount of bugs that stem from this property of the language, I guess I am not alone. ;-)
Pretty much everyone in the video games industry is going to disagree with this. Performance is the primary concern there, period. Languages that reject such ideas in favor of others simply will not be used, given a choice. Consoles also only run signed code, enforce NX, and mprotect doesn't exist, so there is very little in what can be exploited.
> Languages that reject such ideas in favor of others simply will not be used, given a choice.
That is the key issue, "given a choice".
I saw game developers being dragged into accepting C was replacing their beautiful Assembly, followed by game developers being dragged into accepting C++ was replacing their beautiful C.
You can be pretty sure if tomorrow Sony, Apple, Nintendo, Google or Microsoft said "you must use language X", they would do it.
So yeah, given the choice they can continue to lose money thanks to memory corruption exploits.
Signed code and NX don't protect against memory corruption. One can use ROP to work around it.
Again, bounds checking really doesn't show up in profiles. Iterators have none, and LLVM removes most of the ones that remain. It's really a non-issue.
As if it couldn't be used to exploit and pirate the games, get extra lifes, buy in-game items without paying, automate bots...
"Many years later we asked our customers whether they wished us to provide an option to switch off these checks in the interests of efficiency on production runs. Unanimously, they urged us not to--they already knew how frequently subscript errors occur on production runs where failure to detect them could be disastrous. I note with fear and horror that even in 1980, language designers and users have not learned this lesson. In any respectable branch of engineering, failure to observe such elementary precautions would have long been against the law."
- C.A.R Hoare Turing Award speech, 1980