This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Small update to reversed_comparison_code
- To: kenner at vlsi1 dot ultra dot nyu dot edu, mrs at windriver dot com
- Subject: Re: Small update to reversed_comparison_code
- From: dewar at gnat dot com
- Date: Wed, 14 Mar 2001 07:50:41 -0500 (EST)
- Cc: gcc at gcc dot gnu dot org
<<You miss my point. Testing would have given the wrong answer. It would
have said "There's something wrong with this patch". But there isn't: there
was some unrelated latent bug. >>
I know Richard feels this way, but I disagree, if something is working and
then you make a change, and it does not work any longer, then there is
indeed something wrong with the change.
Yes, from the developer's point of view, the patch is "correct", but that
is not interesting if it breaks something. A latent bug is not a defect
in operational terms, only in maintenance terms.
If a fix is needed for a problem P, and the obvious fix triggers a latent
bug, then fixing this latent bug is part of the solution for P, and any
patch that does not address the latent bug is an incomplete solution for P.
Sure, Richard is right that sometimes the burden of fixing a latent bug
might be arbitrarily high, but that just means that the developer may
need to ask for help.
A real danger here is priority inversion caused by such latent bugs. If
someone fixes a non-urgent bug with an incomplete fix, leaving builds broken,
then suddently the non-urgent bug gets effectively elevated to super-urgent
status because the builds are broken. Now if problem P was sufficiently
super-urgent, that may be justified, but all too often that is NOT the case.
Robert Dewar