Out of range pointers

[Barnacle Wes]

In article <835 at proxftl.UUCP> bill at proxftl.UUCP (T. William Wells) writes:
> ... I routinely write code that does not do *any* parameter
> validation.  And my debugged code almost never breaks in a way
> that would have been caught by parameter validation (or, for that
> matter, by most of the other tricks of the robust-is-god school),

In article <1988Oct1.221726.10698 at utzoo.uucp>, henry at utzoo.uucp (Henry Spencer) replied:
| The experience of preparing my regexp library for posting convinced me
| that time spent in more paranoid testing is almost never wasted.  The code
| was ready to go (I thought).  I did up a quick regression-test widget
| so that other people could tell whether the thing was working on their
| weird machine after being compiled by their weird compiler.  I ran it
| on my machine and several of the test cases failed.  Oops.  I then spent
| considerably more effort on building a fairly thorough set of test cases,
| over 100 of them.  It paid off.  The thing *STILL* had a bug or two that
| were found by others after I posted it, but it was much more solid than
| when I *first* thought it was ready to post.

After having worked in software testing and validation for over 4 years,
I have gotten pretty good at breaking code.  During the developement
testing, whenever we got a new build of the software, our boss expected
us to break it somehow in the first night.  We didn't let her down,
through 11 released builds and several dozen "engineering versions."  If
your code is not written in the "robust-is-god" manner, I can break it
easily.  If it is written carefully, I can probably still break it,
using inputs your code considers valid.  Whenever I am confronted with
the old line "I don't need to test/document/debug it, it already works,"
I have one simple answer: "Prove it!"
-- 
                     {hpda, uwmcsd1}!sp7040!obie!wes

         "How do you make the boat go when there's no wind?"
                                 -- Me --