Bounds checking

Bounds checking is the name given to any method of detecting whether or not the index given lies within the limits of the array. For example, accessing index 25 on an array of size 10 would be caught by bounds checking as an invalid index, because it does not lie within the specified size limit of the array.

Because performing bounds checking during every access of an array is inefficient and in some applications unacceptable, there are compiler technologies for eliminating bounds checking in many common cases when they are provably not needed; see bounds checking elimination.

Many mainstream languages of the 1980s and 1990s, such as C, C++, and Pascal, did not ever perform automatic bounds checking, in the interest of efficiency. However, this has been a source of innumerable errors; although necessary in some cases, many believe these languages sacrifice too much in the search for rapid execution. In his 1980 Turing Award lecture (1), C. Antony R. Hoare, describing his experience in the design of Algol 60, which included bounds checking, said:

A consequence of this principle is that every occurrence of every subscript of every subscripted variable was on every occasion checked at run time against both the upper and the lower declared bounds of the array. Many years later we asked our customers whether they wished us to provide an option to switch off these checks in the interest 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.

Mainstream languages that enforce run time checking include Java and C#. These are relatively new languages.

References

• The Emperor's Old Clothes, The 1980 ACM Turing Award Lecture, CACM volume 24 number 2, February 1981, pp 75-83.