Murray Lesser wrote to Eddy Thilleman on 01-20-1999

ML>     The chances of finding a "fatal" bug in PL/I at this late date
ML> is pretty small :-).  I have only found one bug in PL/I for OS/2
ML> thus far (in 1996) and wrote a workaround for it before I reported
ML> it to IBM.  (I have found it most useful to include the workaround
ML> with the bug report; it is of great help to the bug-swatter.)  I was
ML> later told by a long-term PL/I user that my bug had been in the
ML> language since mainframe days, and everyone just lived with it!  By
ML> coincidence, a CSD for that version of the compiler was in the
ML> making at the time, so the bug fix was shipped the following month. 
ML> Actually, bugs in language processors (compilers) are very rarely
ML> fatal (for a well-designed language) because there are always
ML> several ways to accomplish the same task.  I am not so sure that
ML> this statement applies to drag-and-drop "application builders," but
ML> I don't use them.

Speaking of long-time bugs, Visual Age C++ V3 still has the same bug
in the optimizer where a specific sequence will cause it to 'optimize'
out the save of the SI register - try tracking down a bug like that! 
As you say, tho, you can work around it by turning optimization off for
those routines.  In fact, that's how we found it.  Divide and conquer: 
turn optimizations on one by one til it crashes, then keep narrowing
the range until you get to a managable amount of code to trace.  Don't
ever let anyone convince you that a working knowlege of assembler level
coding isn't valuable!  I suspect that this optimization bug may lurk
in some other languages as well since code optimization, at least the
final stages, is pretty well language independent.

Will Honea 

___
 X KWQ/2 1.2i X Us Old Farts don't have to be politically correct.

--- Maximus/2 2.02