Compiler errors vs. runtime behavior

Compiler errors vs. runtime behavior

[Michael Feldman]

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

Re: Compiler errors vs. runtime behavior

[spool.mu.edu!sgiblab!public!heard]

In article <1992Dec13.202938.4595@seas.gwu.edu> mfeldman@seas.gwu.edu (Michael 
Feldman) writes:
> [...] Would you rather debug at compile time or run time?

At compile time.

ANY day.

- heard

Re: Compiler errors vs. runtime behavior

[Gary Morris @pulsar]

In <1992Dec13.202938.4595@seas.gwu.edu> mfeldman@seas.gwu.edu (Michael Feldman)
writes:
>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....

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

Actually, we have a case of a single character error in Ada that we have hit a
couple times and have learned to watch out for.  We prefer to avoid the "use"
clause and so we end up with lots of operator renames in package bodies.  Here
is what sometimes happens, see if you can readily spot the error. 

with Unix_Types;
package body POSIX_Process_Times is

  package UT renames UNIX_Types;

  function "=" (L,R: UT.Int) return Boolean renames UT."=";
  function "+" (L,R: UT.Int) return UT.Int  renames UT."+";
  function "-" (L  : UT.Int) return UT.Int  renames UT."-";
  function "*" (L,R: UT.Int) return UT.Int  renames UT."*";
  function "/" (L,R: UT.Int) return UT.Int  renames UT."/";

  function "<" (L,R: UT.Unsigned_Short) return Boolean renames UT."<";
  function "+" (L,R: UT.Unsigned_Short) return UT.Unsigned_Short renames UT."+"
;
  function "-" (L,R: UT.Unsigned_Short) return UT.Unsigned_Short renames UT."+"
;

  ...

end POSIX_Process_Times; 


The last rename of the "-" operator is actually renaming UT."+" to "-". 
The way it happens is that someone needs another rename declaration,
duplicates the "+" declaration line and then changes the operator on the
left and forgets to change the one on the right. 

It's hard to find this at first, you have some arithmetic expression giving
the wrong result (which you must first find), then you examine the
expression to figure out why it gives the wrong result.  But the expression
*looks* just fine, until you realize that the "-" operator is not doing what
what you expect, in this context 5-3 is 8. The first time I did this it took
quite a while to realize what was wrong. 

There has been a suggestion to have our compiler give a compile time warning
on a rename where the operators don't match.  Perhaps this is a case of too
much redundency in the language (without any cross checking). 
--GaryM
-- 
Gary Morris                      Internet: garym@telesoft.com
Ada Software Development         UUCP:     uunet!telesoft!garym
Alsys West (TeleSoft)            Phone:    +1 619-457-2700
San Diego, CA, USA               Fax:      +1 619-452-2117