albaugh@dms.UUCP (Mike Albaugh) (12/17/88)
From article <8008@aw.sei.cmu.edu>, by firth@sei.cmu.edu (Robert Firth): > [... many comments about compilers muffing single token corrections ] > which is a single-token correction. The real booby price, though, goes > to the C compiler where omitting a semicolon before a right brace: > > if (...) { s1; s2 } > > causes an indefinite number of bogus consequential errors, until either > the compiler gives up "too many errors - goodbye" or your program text > ends. Since the repair here is perhaps the simplest possible, this > compiler feature represents incompetence of a rare order. Actually my nominee is the VAX-11C (vms) compiler which "corrects" if ((( ... expression )) { .... to if ((( ... expression ))) ... That is, rather than inserting the required paren to balance the expression, it _replaces_ the '{' with a ')'. Needless to say, the corresponding brace imbalance leads to a torrent of further errors. I'm not a compiler writer (But I've played one on occasion :-)), but I thought that insertion was typically tried before substitution in this sort of case. Can any of you compiler gurus explain why this particular choice was made. Oh, yeah, we reported it but no reply and it's still there 3 versions later... | Mike Albaugh (albaugh@dms.UUCP || {...decwrl!turtlevax!}weitek!dms!albaugh) | Atari Games Corp (Arcade Games, no relation to the makers of the ST) | 675 Sycamore Dr. Milpitas, CA 95035 voice: (408)434-1709 | The opinions expressed are my own (Boy, are they ever)
skh@hpclskh.HP.COM (12/20/88)
> Actually my nominee is the VAX-11C (vms) compiler which "corrects" > > if ((( ... expression )) { .... >to > if ((( ... expression ))) ... > > That is, rather than inserting the required paren to balance the >expression, it _replaces_ the '{' with a ')'. Needless to say, the >corresponding brace imbalance leads to a torrent of further errors. >I'm not a compiler writer (But I've played one on occasion :-)), but >I thought that insertion was typically tried before substitution in >this sort of case. Can any of you compiler gurus explain why this >particular choice was made. Oh, yeah, we reported it but no reply and >it's still there 3 versions later... > >Mike Albaugh (albaugh@dms.UUCP || {...decwrl!turtlevax!}weitek!dms!albaugh) Yes, most correction schemes do try insertion before replacement. And in examples from earlier postings (not shown), many correction schemes refuse to delete a symbol (thus leading to the frustrating ";" before "ELSE" problem). At one time, deletion was considered in very bad taste, since the token was obviously provided by a programmer. Newer correction schemes are much better. However, I have found few production compilers which implement the newest error correction schemes. And replacing the error correction routines in a WORKING compiler seems to be rare (probably thought to be not worth the maintenance cost). Working in the compiler field myself, I find this a sad fact, but I can see the reasons. Real compiler bugs always take precedence over mediocre (or even poor) error correction. skh skh%hpclskh@hplabs.hp.com