🚀 go-pugleaf

Next semester, a class of mine will be running some experiments to see
how expensive and effective a particular testing technique is.  We're
going to test GNU programs, because they're nicely representative.
We'll take routines with bugs, write driver routines if necessary, and
hand them to the students.

We'll be monitoring the GNU bug lists to find likely bugs.  But I
anticipate a lot of wasted time discovering that bugs aren't really
bugs, FTPing files only to discover that the routine with the bug will
be too difficult to write a driver for, and so on.  GNU developers can
help out -- if you fix a bug in a routine that looks useful to us,
could you drop us a note, just something that says "Check out this bug
in version 1.34; here's the diff"?

A useful bug is one which

- is a coding bug, not a design bug.  That is, the code didn't do what
you intended, rather than what you intended was wrong.

- occurs in a routine whose input is fairly simple to understand and
provide.  A bug in main, for example, would be good because we don't
have to write any special-purpose driver code.  A bug in some
RTL-processing code in gcc would be bad -- it would take too long to
explain RTL and to make it easy for the students to specify what RTL
the routine should be given.  (However, routines that take structure
arguments and simple lists would be fine -- too much testing research
has been on overly simple routines that take integer arguments.)

Please send the mail to bugs@ernie.cs.uiuc.edu.

Thanks -- this will be useful to programmers.

Brian Marick
Motorola @ University of Illinois
marick@cs.uiuc.edu, uiucdcs!marick