Path: utzoo!utgpu!utstat!jarvis.csri.toronto.edu!mailrus!uflorida!novavax!hcx1!hcx2!bill
From: bill@hcx2.SSD.HARRIS.COM
Newsgroups: comp.lang.fortran
Subject: Re: Using END= and ERR= in READs
Message-ID: <44400033@hcx2>
Date: 23 Feb 89 15:59:00 GMT
References: <436@orange19.qtp.ufl.edu>
Lines: 26
Nf-ID: #R:orange19.qtp.ufl.edu:436:hcx2:44400033:000:1213
Nf-From: hcx2.SSD.HARRIS.COM!bill    Feb 23 10:59:00 1989


> The '77 standard tells me that "The set of input/output error
> conditions is processor dependent." That seems to give someone the
> leeway to *not* handle end-of-files with ERR= if no END= is present,
> and (of course) I have a case in which this occurs (SunOS 3.4 f77).
> 
> Can anyone tell me if this "hole" was intentional, or an oversight?
> If it was intentional, what is the logic?  It seems rather inane to
> have to put in "END=8800, ERR=8800" into every READ statement.

There is _no_, repeat _no_, leeway in this matter.  I refer you to Section
12.6 of X3.9-1978: "... or if an end-of-file condition occurs during
execution of a READ statement that contains neither an input/output status
specifier nor an end-of-file specifier (12.7.2), execution of the
executable program is terminated."

In other words, if you don't have a STATUS= nor an END=, an end-of-file
condition is _not_ handled by the ERR=; the program terminates.  Any
implementation that takes the ERR= branch in this situation is a
non-conforming implementation.

Bill Leonard, Member X3J3
Harris Computer Systems Division
2101 W. Cypress Creek Road
Fort Lauderdale, FL  33309
bill@ssd.harris.com or bill%ssd.harris.com@eddie.mit.edu