Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!uwm.edu!cs.utexas.edu!uunet!mcsun!sunic!tut!tukki!sakkinen From: sakkinen@tukki.jyu.fi (Markku Sakkinen) Newsgroups: comp.lang.fortran Subject: Re: Standard conformance Message-ID: <1412@tukki.jyu.fi> Date: 3 Oct 89 15:31:46 GMT References: <1301@tukki.jyu.fi> <612@mbph.UUCP> <1099@key.COM> Reply-To: sakkinen@jytko.jyu.fi (Markku Sakkinen) SAKKINEN@FINJYU.bitnet (alternative) Organization: University of Jyvaskyla, Finland Lines: 70 In message <1301@tukki.jyu.fi> from sakkinen@tukki.jyu.fi, I presented a sample programme about an illegal jump into a DO loop, in which many current compilers are unable to find the error. In message <612@mbph.UUCP>, hybl@mbph.UUCP (Albert Hybl) writes: >... >It also contains another serious error; the variable I is used >in an expression before it is assigned a value. Is that legal >in X3.9-1978 fortran or is it just another allowed extension? >Are there any implementations that detect this type of error? >Why aren't all standard conforming compilers required to detect >and report such errors? The following are the results obtained >from the 3B2/XLA+ and the 3B1/SVS implementations: >... You are right: this was a lazily written example, although it was good enough to demonstrate the point I wanted. If there had been only an unconditional GOTO, many compilers would have given some warning like "No path to statement" (i.e., to the DO statement). In the following form, the other error would be eliminated: SUBROUTINE GOTODO (I) INTEGER I, J IF (I .LT. 100000) GOTO 2 DO 9 I = 1, 10 ... In general, the question of whether every variable is assigned a value before it is used in an expression cannot be determined at compile time. Namely, if a variable is used as an argument in a subroutine or function call, it _might_ be assigned a value there. Alternatively, the formal argument might be _used_ in the subroutine/function, thus requiring an assignment before the call. In article <1099@key.COM> sjc@key.COM (Steve Correll) writes: >... >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. [...] >... > > 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. >... The point I wanted to make was mainly: If a compiler is advertised to detect deviations from the standard, it should really do so as far as feasible! And allowing jumps into DO loops is certainly a "proving-ground" for the standards of the _past_! Markku Sakkinen Department of Computer Science University of Jyvaskyla (a's with umlauts) Seminaarinkatu 15 SF-40100 Jyvaskyla (umlauts again) Finland