Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!ucbvax!decwrl!pyramid!prls!mips!rogerk
From: rogerk@mips.COM (Roger B.A. Klorese)
Newsgroups: comp.lang.fortran
Subject: Re: Using END= and ERR= in READs
Message-ID: <14499@admin.mips.COM>
Date: 3 Mar 89 06:03:46 GMT
References: <436@orange19.qtp.ufl.edu> <14166@admin.mips.COM> <448@orange19.qtp.ufl.edu>
Reply-To: rogerk@mips.COM (Roger B.A. Klorese)
Organization: MIPS Computer Systems, Sunnyvale, CA
Lines: 28

In article <448@orange19.qtp.ufl.edu> bernhold@orange19 (David E. Bernholdt) writes:
>In article <14166@admin.mips.COM> rogerk@mips.COM (Roger B.A. Klorese) writes:
>>No, your experience with VMS FORTRAN tells you this.  End-of-file is not
>>considered an error in FORTRAN 77, but an expectable condition; it is not
>>necessarily subject to handling via ERR=.
>Actually, VMS FORTRAN has nothing to do with it.  Can you show me a
>FORTRAN compiler that does NOT produce and ERROR message on an
>end-of-file if it is not trapped?  I haven't yet seen one.

The runtime (not the compiler) produces an END-OF-FILE message, which
is usually handled by terminating the program.  This is *not* an error
message.

>I understand what the standard says about EOF and error conditions.  I
>also understand how to use IOSTAT.  The point I was trying to make
>when I asked the question is why does and EOF have to be trapped
>separately in all cases, when as far as the computer is concerned one
>is just as much an error as the other?

"As far as the computer is concerned", a record number which produces an
overflow condition when computed would be "just as much an error as the
other"; would you have this handled by the ERR= clause as well?

-- 
Roger B.A. Klorese                                  MIPS Computer Systems, Inc.
{ames,decwrl,pyramid}!mips!rogerk      928 E. Arques Ave.  Sunnyvale, CA  94086
rogerk@servitude.mips.COM (rogerk%mips.COM@ames.arc.nasa.gov)   +1 408 991-7802
"I majored in nursing, but I had to drop it.  I ran out of milk." - Judy Tenuta