Re: Java: Helping the world build bigger idiots
On 9/22/05, [EMAIL PROTECTED] (Olle Mulmo) wrote:
Peter's example is standard to the language. It's just not used much
by those influenced by other idioms prior to learning Java.
I guess another way of saying this is: the people on this list are
getting old. :-)
I guess insisting on correct error handling is just for old people.
Peter's example:
try {
int idx = 0;
while (true) {
displayProductInfo(prodnums[idx]);
idx++;
}
}
catch (IndexOutOfBoundException ex) {
// nil
}
has a serious bug in error handling. We do not know where the
IndexOutOfBoundException was raised. Was it raised in the while loop,
the expected case; or was it raised in the displayProductInfo method,
due to some bug in that method? (It could also be raised in some other
method called by displayProductInfo.)
In order for this code to be correct, we would have to prove that the
displayProductInfo method either could not raise this exception, or that
it caught and handled any IndexOutOfBoundException exceptions raised in
it or in methods it calls. In either case, we must examine the details of
displayProductInfo, and depend on our conclusions remaining correct
during maintenance. This level of coupling between caller and callee is
too risky for reliable software.
Cheers - Bill
-
Bill Frantz| The first thing you need | Periwinkle
(408)356-8506 | when using a perimeter | 16345 Englewood Ave
www.pwpconsult.com | defense is a perimeter.| Los Gatos, CA 95032
-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Java: Helping the world build bigger idiots
In message [EMAIL PROTECTED], Steve Furlong writes: On a related note, I've worked a bit with avionics and embedded medical software. The certification requirements for those bits of critical code might be helpful for crypto programming. Not quite. The name of the game is information security, and that's far more than crypto. Sometimes, in fact, the two conflict. --Steven M. Bellovin, http://www.cs.columbia.edu/~smb - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Java: Helping the world build bigger idiots
On 2005-09-20, Jerrold Leichter wrote:
One thing to consider is that an idiom like this solves an annoying problem.
Consider a linear search through an array:
for (i = 0; i lim; i++)
{ if (a[i] == target)
{ do something
break;
}
}
/*
* Did we get here because we matched or because we
* failed to match?
*/
No, we got here because we didn't know basic C usage. Come on
people, please stop creating these fake illustrations.
A real C programmer would have known that, if i == lim, there
was no match. This is so trivial it beggars belief that it
needs to be pointed out in a forum like this.
Personally, I sometimes use:
for (i = 0; i lim; i++)
{ if (a[i] == target)
goto found;
}
This draws shock and horror from some code readers, but I don't care. :-)
Note how much it looks like the exception-based code.
It only draws gasps from people who don't know C. The goto that
is famously considered harmful is not spelled goto in C, but
rather longjmp; it's not used all that often and does need
careful handling. The C goto statement is purely a local goto
and scares nobody who has grown up.
Greg
-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Java: Helping the world build bigger idiots
| One thing to consider is that an idiom like this solves an annoying
problem.
| Consider a linear search through an array:
|
| for (i = 0; i lim; i++)
| { if (a[i] == target)
| { do something
| break;
| }
| }
| /*
| * Did we get here because we matched or because we
| * failed to match?
| */
|
| No, we got here because we didn't know basic C usage. Come on
| people, please stop creating these fake illustrations.
Oh, come on. This loop has a trivial increment and a trivial stopping
condition, for the purpose of illustration. But even here, it's not so
simple. Better style in general is to limit the loop variable's scope to the
loop:
for (int i = 0; i lim; i++)
{ }
Now i isn't accessible after the loop is done. My personal style has always
been to treat the loop variable as local to the loop, even when C didn't let
you declare it that way. There are exceptions - especially cases where you
traverse the same array in two consecutive loops, the second picking up where
the first ended - but I've generally found that to be a better style.
| A real C programmer would have known that, if i == lim, there
| was no match. This is so trivial it beggars belief that it
| needs to be pointed out in a forum like this.
|
| Personally, I sometimes use:
|
| for (i = 0; i lim; i++)
| { if (a[i] == target)
| goto found;
| }
|
| This draws shock and horror from some code readers, but I don't care. :-)
| Note how much it looks like the exception-based code.
|
| It only draws gasps from people who don't know C. The goto that
| is famously considered harmful is not spelled goto in C, but
| rather longjmp; it's not used all that often and does need
| careful handling. The C goto statement is purely a local goto
| and scares nobody who has grown up.
Nice to know we're all adults here :-)
-- Jerry
-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Java: Helping the world build bigger idiots
On 9/20/05, Rich Salz [EMAIL PROTECTED] wrote: This is wandering way far afield of the list charter. In an effort to maintain some relevance, I'll point out that code reviews, and crypto programming, are rarely done, and arguably shouldn't, by programming wizards. If by that you mean, Program dumb: avoid tricky code, avoid odd usage, stick to the basics, I agree. Save your clever tricks for hobby code and the snippets you use to score hot chicks. Critical code, potentially dangerous code, and professional code should be written simply and with the idioms standard to the language. On a related note, I've worked a bit with avionics and embedded medical software. The certification requirements for those bits of critical code might be helpful for crypto programming. -- There are no bad teachers, only defective children. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Java: Helping the world build bigger idiots
It used to be that checking bounds on certain collections was less
efficient than waiting for the out of bounds exception. I think Joshua
Bloch discusses this in his book.
I've also seen this in generated code where you aren't sure of the
nature of the object you're indexing and thus don't know the
appropriate length variable (.length vs .length()).
That said it's still awful.
On 9/19/05, Peter Gutmann [EMAIL PROTECTED] wrote:
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
}
The editor also comments that when he got the first few of these submitted he
rejected them as being faked, but ended up with so many that he realised this
usage must be relatively common.
Peter.
-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
--
Jeremiah Rogers
-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Java: Helping the world build bigger idiots
On 9/19/05, [EMAIL PROTECTED] (Peter Gutmann) wrote:
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
}
This is obviously just an attempt to make Java array access more like Java file
access. :-)
Seriously, the real flaw in this approach, which I did not see mentioned in the
comments on the web page Peter references above, is the masking of
IndexOutOfBoundExceptions that may be generated by displayProductInfo. This
code will treat such errors as end of array. A more normal coding of the
loop:
for (int i=1; iprodnums.length; i++) {
displayProductInfo(prodnums[idx]);
idx++;
}
would let the exception pass up the call chain, and with good error handling,
the problem would come to the attention of those responsible for fixing the
program.
If ArrayIndexOutOfBoundException were used instead of IndexOutOfBoundException,
errors in string indexing would pass up the call chain, while catching array
problems.
Cheers - Bill
-
Bill Frantz| The first thing you need | Periwinkle
(408)356-8506 | when using a perimeter | 16345 Englewood Ave
www.pwpconsult.com | defense is a perimeter.| Los Gatos, CA 95032
-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Java: Helping the world build bigger idiots
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
}
The editor also comments that when he got the first few of these submitted he
rejected them as being faked, but ended up with so many that he realised this
usage must be relatively common.
Peter.
-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Java: Helping the world build bigger idiots
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]
