Article omissions and just a failure to test?
There's a few things in this article that warrant a bit more explanation.
'They were using RS6000s to do the maintenance from the screen, no permanent printed copies were used,' - this seems unlikely but perhaps the key word is permanent. The obvious question here is the cost and lack of mobility of the RS/6000 and its hefty CRT screen. It's more likely to be in a clean office environment, away from the less-clean, huge aircraft. I wonder if the software had annotation features too. "from the screen" seems unlikely for a lot of work.
'Pete told us, "it turned out [to be] an optimisation bug in the IBM C compiler used on the RS6000. It was overwriting registers that were being used to store local C variables when the call stack got too deep." ' - this feels like it needs an extra line or two of explanation, you can't normally just trample on registers. If this is about preserving values for the calling convention then why did it fail at a certain stack depth? That doesn't make sense. The POWER architecture doesn't use a register window, AFAIK?
As others (@Wellyboot and first Anonymous Coward replying to @Giovani Tapini) have pointed out, principally this appears to be a failure of testing to verify that a representative manual (or two!) was rendered with the same content of the originals. The most basic manual test beyond looking at page 1 is to go to the end and see how many pages there are in total. That would have caught this problem (' "After about 30 pages I reached a page where my Windows app showed more data than the RS6000 app" ') so again it feels like more explanation is needed. Perhaps repagination is an issue here but probably not as would they really want to change the page numbers?
@boltar, @svm, @MacroRodent and @Herby have some very pertinent points and sound advice that many of us will have forgotten. It's worth running tests both with an unoptimised and optimised program. This could uncover ultra-rare compiler bugs but more likely highlight bugs in code which is relying on undefined behaviour in the language which the optimiser happens to change. This is another omission from this article, whether the code was relying on languages features that had undefined behaviour.
I'd also highlight the value of compiling on different platforms and comparing test results even if you don't intend to use each target in production. This can be a useful and fairly cheap way to find bugs like this and others.
Reporting ' "I saw no press reports of bad maintenance." ' is a bit disingenuous. Does Pete scan all the press? Does he read the aviation trade press? Did the article author go back and look for this? Was this newsworthy enough for a journalist to cover? Were there any incidents are accidents linked to this problem, presumably not?
Biting the hand that feeds IT
