John Deighan wrote: > > The problem comes when you have a function that computes an index, > it's buggy and returns a negative number.
The point is to debug your code properly. You can't expect buggy code to work properly anywhere. This is just one spot where a bug in your code could cause you to go a while longer before realizing it, but that's still no excuse for the bug being there in the first place. It's the bug that's causing the problem, not the feature. > Using that index returns > incorrect data instead of an undefined value, which makes it much > harder to detect that bug. Besides, what's so hard about > saying [EMAIL PROTECTED] as opposed to $array[-1] ? Nothing, but there's always a trade-off between extra features and possbile misuse of same. When you design a language, you can't possibly think of all the misuses that can occur due to bugs. > You can trap errors and warnings. We usually inform the user that > something went wrong, but send a detailed error message via an e-mail > to ourselves. I think that most users would rather be told that > something went wrong than to get incorrect data. Incorrect data that > is taken as correct data can lead to very bad things. Again, you can only get incorrect data if you have a bug in your code. > Lack of automatic bounds checking (at least in cases where the > boundaries are fixed, so this doesn't really relate to Perl) is > responsible for all the "buffer overflow" security holes we find > outselves having to deal with. > > I totally agree that all data entered by users needs to be thoroughly > checked, but that's a different issue than whether we programmers > should have to implement bounds checking for every time we index into an > array. You only have to check where you didn't compute the index yourself (providing of course that you properly code your index computations). _______________________________________________ Perl-Win32-Users mailing list Perl-Win32-Users@listserv.ActiveState.com To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs
