In message <[EMAIL PROTECTED]>, Peter Gutmann writes
:
>Found on the Daily WTF, http://www.thedailywtf.com/forums/43223/ShowPost.aspx:
>
> try {
> int idx = 0;
>
> while (true) {
> displayProductInfo(prodnums[idx]);
> idx++;
> }
> }
> catch (IndexOutOfBoundException ex) {
> // nil
> }
>
As opposed to the C version:
int idx = 0;
while (true) {
displayProductInfo(prodnums[idx]);
idx++;
}
printf("Segmentation error; core dumped\n");
If it were input, it would print "you are now 0wned"...
No, Java isn't the solution to the world's programming problems. But
bounds-checking -- in any language! -- would be a very big help.
The first principle was security: The principle that every
syntactically incorrect program should be rejected by the
compiler and that every syntactically correct program should
give a result or an error message that was predictable and
comprehensible in terms of the source language program
itself. Thus no core dumps should ever be necessary. It
was logically impossible for any source language program
to cause the computer to run wild, either at compile time
or at run time. 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
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.
>From Tony Hoare's 1980 Turing Award lecture.
--Steven M. Bellovin, http://www.cs.columbia.edu/~smb
---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
