home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #30 / NN_1992_30.iso / spool / comp / lang / ada / 3650 < prev    next >
Encoding:
Text File  |  1992-12-13  |  3.3 KB  |  70 lines

  1. Newsgroups: comp.lang.ada
  2. Path: sparky!uunet!seas.gwu.edu!mfeldman
  3. From: mfeldman@seas.gwu.edu (Michael Feldman)
  4. Subject: Compiler errors vs. runtime behavior
  5. Message-ID: <1992Dec13.202938.4595@seas.gwu.edu>
  6. Sender: news@seas.gwu.edu
  7. Organization: George Washington University
  8. References: <921212103914.20203764@OTTAWA.DSEG.TI.COM>
  9. Date: Sun, 13 Dec 1992 20:29:38 GMT
  10. Lines: 58
  11.  
  12. In article <921212103914.20203764@OTTAWA.DSEG.TI.COM> PETCHER@OTTAWA.dseg.ti.com (What? Me Ada?) writes:
  13. >
  14. >I would submit that neither of these warnings is completely correct for this
  15. >particular example, at least without further qualification.  'x' is, in fact,
  16. >used after assignment, although both the assignment and the subsequent use
  17. >could be optimized away.  If they are, the compiler should state that in the
  18. >warning.  If not, no warning should be given.  If you really put the
  19. >offending semicolon in by accident, but the program compiled OK anyway, even
  20. >with the warning, you'd say "Of course it's used.  Compiler bug." then get in
  21. >there with a debugger and wonder why you couldn't find 'x' or any code
  22. >associated with it.  The warning about the infinite loop should only be given
  23. >if the compiler supports the "volatile" storage class modifier.  Most do, and
  24. >I think the ANSI standard requires it, but not all compilers support it just
  25. >the same, or just ignore it.  The result is something outside the current
  26. >context could change the value of x and terminate the loop.
  27.  
  28. All of which shows just how subjective - and therefore controversial -
  29. is the whole area of compiler warnings, or advisories, or whatever, that
  30. go beyond detection of compile-time errors. Even error _repair_ - so that
  31. the compiler does not have to bail out on the first error - is a bit
  32. dicey, because the repair is so often wrong.
  33.  
  34. The point of my post about the C semicolon _accidentally_
  35. causing an infinite loop with a single keystroke error, and the 
  36. preceding post about the Fortran comma-vs.-error, is that we ought to
  37. design our languages so that the probability of this kind of error is
  38. minimized. This is done by building enough redundancy into the syntax
  39. (using e.g. fully-bracketed control structures, Ada's use of which is
  40. _horribly_ verbose to many C folks) so that what would otherwise be an
  41. undetectable runtime error is turned into an easily detectable
  42. compile-time error. This is the whole point of verbose (OK, I'll
  43. use the nay-sayers' term) strongly-typed languages. 
  44.  
  45. The only comparable case in Ada is the ";" vs. "IS" problem, which
  46. leads to confusing compilation errors but at least it doesn't cause
  47. obscure run time behavior.
  48.  
  49. Once again we come back to undebatable matters of taste: one person's
  50. verbosity is another's safety-enhancing redundancy (fault tolerance, if
  51. you will). Would you rather debug at compile time or run time?
  52.  
  53. Cheers -
  54.  
  55. Mike Feldman
  56. ------------------------------------------------------------------------
  57. Michael B. Feldman
  58. co-chair, SIGAda Education Committee
  59.  
  60. Professor, Dept. of Electrical Engineering and Computer Science
  61. School of Engineering and Applied Science
  62. The George Washington University
  63. Washington, DC 20052 USA
  64. (202) 994-5253 (voice)
  65. (202) 994-5296 (fax)
  66. mfeldman@seas.gwu.edu (Internet)
  67.  
  68. "Americans want the fruits of patience -- and they want them now."
  69. ------------------------------------------------------------------------
  70.