Re: Moving towards GCC 3.1

[kenner at vlsi1 dot ultra dot nyu dot edu (Richard Kenner)]

    > (3) Fixing latent bugs

    Not granted as a separate category.  If it's a latent bug, then
    it must fall into 1 or 2, or have a new test case.

By "latent", I mean a bug that is observed by reading code (or while
searching for a bug which was elsewhere) but which cannot at present
cause problems because something else (perhaps another bug) prevents
it from being relevant.  For example, it would occur only on a target
machine with two values of macros and we don't have any such, at present.
This sort of bug is a timebomb and should be fixed as soon as it is
discovered, but, by definition you can't come up with a test case for it.

    Define "code quality issues".  

Code that doesn't meet the coding standards, is inadequately documented,
is unclear, or similar.  Part of getting ready for a release is to make
a pass over files and ensure we are meeting our documentation and
coding standards.  I've gone through nine files and fixed what I could (but
I can't add missing documentation), but others needs to pick up the ball
with the rest of the files and fill in the missing documentation for those.

    It's funny, because I work with proprietary test suites all the time,
    and about 2/3 of the time I manage to generate an independant test
    case from problems seen there.  More if you discount reload problems.

My experience is a lower number, which may be due to differences
between typical C and Ada programs, but whatever the number, I don't 
think we want to say that only the ones where test cases can be generated
should be fixed during this development phase.