Java: Helping the world build bigger idiots

Steven M. Bellovin smb at
Mon Sep 19 11:28:51 EDT 2005

In message <E1EHJxx-0006SI-00 at>, Peter Gutmann writes
>Found on the Daily WTF,
>  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) { 
    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,

The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at

More information about the cryptography mailing list