Jan,

I feel the pain involved with looking for such a simple bug taking a long time to discover. I've been in those shoes myself a number of times. I don't want to sprinkle salt onto the wound but certainly a point like this is a good time to reflect on what happened.

The resulting inserted code with the now double "dec a" in front of it can be seen to mean that the new function would not be launched with the correct selection code. This does lead to a question of testing. Was the new added feature tested at the time of implementation? If it had been I think the problem would have been found at that time unless the various "DO SOMETHING" sequences did paltry little things that were not easily noticeable by a cursory test.

Also there are many situations where regression testing is not part of a test and code validation process. If that type of testing had been used here one would have probably noted the failure of the subsequent cases in the code sequence...unless of course those test cases results were not covered by the test verification signatures.

Maybe there is a case made here for the value of feature regression testing. This is a clear situation where adding a new feature broke an existing feature.

This may also be a case for certain styles of coding. If a table lookup had been used the code flow would not have broken upon the insertion of a new row in the table. You also mention that several places in the code had to be changed to be able to slip in the new case. This may have been a call for a design that used a table with multiple elements per row to cover each of the function dependencies. Sliding in the new row happens in one place then.

Michael Karas