comp.lang.ada
 help / color / mirror / Atom feed
From: seas.gwu.edu!mfeldman@uunet.uu.net  (Michael Feldman)
Subject: Compiler errors vs. runtime behavior
Date: 13 Dec 92 20:29:38 GMT	[thread overview]
Message-ID: <1992Dec13.202938.4595@seas.gwu.edu> (raw)

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."
------------------------------------------------------------------------

             reply	other threads:[~1992-12-13 20:29 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
1992-12-13 20:29 Michael Feldman [this message]
  -- strict thread matches above, loose matches on Subject: below --
1992-12-16  7:04 Compiler errors vs. runtime behavior spool.mu.edu!sgiblab!public!heard
1993-01-13  7:18 Gary Morris @pulsar
replies disabled

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox