Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!rutgers!usc!apple!ames!amdahl!key!sjc
From: sjc@key.COM (Steve Correll)
Newsgroups: comp.lang.fortran
Subject: Re: Standard conformance
Message-ID: <1099@key.COM>
Date: 21 Sep 89 01:13:40 GMT
References: <1301@tukki.jyu.fi> <612@mbph.UUCP>
Organization: Key Computer Labs, Fremont, CA
Lines: 71

Markku Sakkinen writes:
>The Fortran-77 standard _was_ accepted 11 years ago,
>so one would suppose that the compiler writers have already
>taken notice. Well... take this very simple example of an
>_incorrect_ Fortran programme:
>
>      INTEGER I, J
>      IF (I .LT. 100000) GOTO 2
>      DO 9 I = 1, 10
>2     J = I * I
>      WRITE (6, 100) I, J
>9     CONTINUE
>100   FORMAT (2I12)
>      END
>
>It contains a GOTO into a DO loop, which is illegal in Fortran-77...
>I just tried this kind of example once again with Digital's VAX/VMS
>Fortran compiler, turning on all possible STANDARD and WARNING switches
>(I should think). The result: it compiled without the slightest complaint.

The Fortran 77 standard dictates what a compiler must do with a legal program,
but permits a compiler to do anything it likes with an incorrect one. A
standard-conforming compiler may silently abort, or print a treatise on good
programming hygiene, or correct the error by guessing what you intended to
do, or ignore your program and emit the Towers of Hanoi instead.  See ANSI
X3.9-1978 section 1.4.

One may disagree with the permissiveness of the Fortran 77 committee (the
Fortran 88 committee clearly does) but it is a mistake to say that the example
above demonstrates anything about "standard conformance".

My own opinion:

  1. I think that the way a compiler deals with errors belongs to what the
    ANSI C committee call "quality of implementation", and when you shop for a
    compiler, you must judge this for yourself; no standard can ever entirely
    do this for you. For example, although the Fortran 88 standard requires a
    compiler to detect illegal syntax, it doesn't require error messages to
    cite line numbers. Thus, a compiler could conform merely by printing:

      "There was a syntax error somewhere in your program. Abort."

    Should the standard mandate that error messages contain line numbers? I
    think not. On a Macintosh, many text-editors do not use line numbers, so a
    compiler which printed error messages containing line numbers would be
    inferior to a compiler which showed me the source file with a finger or
    an arrow pointing at the offending line, plus a pop-up window containing
    the error message and a button marked "show next error". Better to let me,
    the compiler-shopper, judge the quality of implementation for myself.

  2. Forbidding extensions is silly, so long as compilers can warn about them,
    because extensions are the proving-ground for the standards of the future.
    
    Besides, if extensions are the worst portability problem you face, you're
    living in paradise. If I give you a large piece of code with a single
    non-portable line inside it, you had better hope it's:

    	BUFFER IN ...

    rather than:

	i_align(i) = iand(z'fff0', i)

    Every conforming Fortran 88 compiler which does not implement BUFFER IN as
    an extension will print an error message telling you about it. By contrast,
    the "i_align" statement function is perfectly legal Fortran 88, but no
    compiler can read the programmer's mind and tell you that this code
    probably stops doing what the programmer intended when you move it from a
    16-bit machine to a 32-bit machine.
-- 
...{sun,pyramid}!pacbell!key!sjc 				Steve Correll