From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.5-pre1 (2020-06-20) on ip-172-31-74-118.ec2.internal X-Spam-Level: X-Spam-Status: No, score=-1.9 required=3.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.5-pre1 Date: 13 Dec 92 20:29:38 GMT From: seas.gwu.edu!mfeldman@uunet.uu.net (Michael Feldman) Subject: Compiler errors vs. runtime behavior Message-ID: <1992Dec13.202938.4595@seas.gwu.edu> List-Id: In article <921212103914.20203764@OTTAWA.DSEG.TI.COM> PETCHER@OTTAWA.dseg.ti.co m (What? Me Ada?) writes: > >I would submit that neither of these warnings is completely correct for this >particular example, at least without further qualification. 'x' is, in fact, >used after assignment, although both the assignment and the subsequent use >could be optimized away. If they are, the compiler should state that in the >warning. If not, no warning should be given. If you really put the >offending semicolon in by accident, but the program compiled OK anyway, even >with the warning, you'd say "Of course it's used. Compiler bug." then get in >there with a debugger and wonder why you couldn't find 'x' or any code >associated with it. The warning about the infinite loop should only be given >if the compiler supports the "volatile" storage class modifier. Most do, and >I think the ANSI standard requires it, but not all compilers support it just >the same, or just ignore it. The result is something outside the current >context could change the value of x and terminate the loop. All of which shows just how subjective - and therefore controversial - is the whole area of compiler warnings, or advisories, or whatever, that go beyond detection of compile-time errors. Even error _repair_ - so that the compiler does not have to bail out on the first error - is a bit dicey, because the repair is so often wrong. The point of my post about the C semicolon _accidentally_ causing an infinite loop with a single keystroke error, and the preceding post about the Fortran comma-vs.-error, is that we ought to design our languages so that the probability of this kind of error is minimized. This is done by building enough redundancy into the syntax (using e.g. fully-bracketed control structures, Ada's use of which is _horribly_ verbose to many C folks) so that what would otherwise be an undetectable runtime error is turned into an easily detectable compile-time error. This is the whole point of verbose (OK, I'll use the nay-sayers' term) strongly-typed languages. The only comparable case in Ada is the ";" vs. "IS" problem, which leads to confusing compilation errors but at least it doesn't cause obscure run time behavior. Once again we come back to undebatable matters of taste: one person's verbosity is another's safety-enhancing redundancy (fault tolerance, if you will). Would you rather debug at compile time or run time? Cheers - Mike Feldman ------------------------------------------------------------------------ Michael B. Feldman co-chair, SIGAda Education Committee Professor, Dept. of Electrical Engineering and Computer Science School of Engineering and Applied Science The George Washington University Washington, DC 20052 USA (202) 994-5253 (voice) (202) 994-5296 (fax) mfeldman@seas.gwu.edu (Internet) "Americans want the fruits of patience -- and they want them now." ------------------------------------------------------------------------