Path: utzoo!attcan!uunet!lll-winken!lll-tis!ames!pasteur!ucbvax!decwrl!purdue!i.cc.purdue.edu!j.cc.purdue.edu!pur-ee!uiucdcs!uxc.cso.uiuc.edu!uxe.cso.uiuc.edu!hirchert
From: hirchert@uxe.cso.uiuc.edu
Newsgroups: comp.lang.fortran
Subject: Re: fortran problem
Message-ID: <50500056@uxe.cso.uiuc.edu>
Date: 15 Jun 88 17:42:00 GMT
Lines: 39
Nf-ID: #R:<8806111222.AA06982@jade.berkele:-38:uxe.cso.uiuc.edu:50500056:000:2188
Nf-From: uxe.cso.uiuc.edu!hirchert    Jun 15 12:42:00 1988


I'd like to make a few more observations on the issue of changing constants
in Fortran:
1. In the most general case, detection _requires_ run-time checks.  Consider
   the following procedure:
      SUBROUTINE SUB(X,ICODE)
      SAVE XX
      IF(ICODE.EQ.0)THEN
         XX=X
      ELSE
         X=XX
      ENDIF
      END
   This routine is correct (according to the rules of Fortran), as long as
   ICODE has the value 0 for each call to SUB where the actual argument
   corresponding to X is not something that can be assigned to.  In general,
   we will not know the value of ICODE until run-time (e.g. it may be read in),
   so no static analysis (whether by the compiler, the linker, or a separate
   "lint" program) can say definitely whether or not this program is correct.
   This is not to say that static analysis is useless.  Static analysis can
   recognize that there is the possibility for error in this procedure and
   can recognize when the erroneous statement is unconditional.
2. Thus, in the general case, checking for this error (or protecting a program
   from the effects of this error) is never entirely without run-time cost.
   The closest one can come to no cost is when the hardware does the checking 
   (as when constants are stored in write-protected memory).  Unfortunately, the
   error messages for hardware detected errors are often cryptic and/or 
   difficult to relate to one's Fortran error.  If hardware detection is either
   unavailable or undesirable, then the compiler must generate extra code,
   either to check for the occurrence of this error or to copy constants to
   storage that can be modified without hurting anything.
3. In turn, this means that it is not necessarily "wrong" to allow programs
   to commit this error.  It depends on whether it is more important to you
   (and your customers) to detect (or protect the program from) errors or to
   achieve maximum performance on correct programs.  (Of course, if you're
   really generous, you can give your customers a choice, just as is usually
   done for subscript bounds checking.)

Kurt W. Hirchert     hirchert@ncsa.uiuc.edu
National Center for Supercomputing Applications