[comp.lang.fortran] ERR= and END=

brainerd@unmvax.unm.edu (Walt Brainerd) (02/25/89)

In a recent posting, Bill Leonard stated that under certain circumstances
involving errors and end-of-file conditions, the processor is required
to terminate execution of the program.  This is true, BUT, there is nothing
to prevent the processor from starting up again one nanosecond later
at any point in the program the implementor chooses.  Thus, from a very
legalistic point of view, it would be my opinion that a processor
that branched (or did most anything else) would NOT violate the standard.
This is an area where reasonableness is enforced by the marketplace,
not the standard itself.

Similarly, a processor that gives an error message when a divide by zero
(forbidden by the standard) is not in violation of the standard,
but is providing an extension to the standard.

khb%fatcity@Sun.COM (fatcity) (02/28/89)

>In a recent posting, Bill Leonard stated that under certain circumstances
>involving errors and end-of-file conditions, ....

>discussion of how ERR= should behave....


Personally, I like to use IOSTAT. Combined with some PARAMETERS which
define the system values (whatever EOF is, etc.) fairly clean code can
then be written, e.g.

	do i = 1, max
	   read(ilun,'(your format)',IOSTAT=istat) your variable list
	   if (istat .EQ. EOF) then
		 EXIT
	   else if (istat .NE. OK) then
	         call abort('your favorite abort messages',istat)
	   endif
	   your processing goes here
	end do

If one doesn't have EXIT, goto label works just fine.

If we assume that goto label is necessary (we are, after all,
discussing f77) only one label is necessary, not two. Many systems
don't error off, or do anything unpleasant when IOSTAT is specified.
Keith H. Bierman
It's Not My Fault ---- I Voted for Bill & Opus

levy@ttrdc.UUCP (Daniel R. Levy) (03/01/89)

In article <91480@sun.uucp>, khb%fatcity@Sun.COM (fatcity) writes:
< 	do i = 1, max
< 	   read(ilun,'(your format)',IOSTAT=istat) your variable list
< 	   if (istat .EQ. EOF) then
< 		 EXIT
< 	   else if (istat .NE. OK) then
< 	         call abort('your favorite abort messages',istat)
< 	   endif
< 	   your processing goes here
< 	end do

Nice idea, but isn't it kind of environment dependent?  Like, where does the
value of the EOF parameter come from?

< If one doesn't have EXIT, goto label works just fine.

Or STOP.
-- 
Daniel R. Levy             UNIX(R) mail:  att!ttbcad!levy
AT&T Bell Laboratories
5555 West Touhy Avenue     Any opinions expressed in the message above are
Skokie, Illinois  60077    mine, and not necessarily AT&T's.

ags@s.cc.purdue.edu (Dave Seaman) (03/01/89)

In article <3234@ttrdc.UUCP> levy@ttrdc.UUCP (Daniel R. Levy) writes:
>In article <91480@sun.uucp>, khb%fatcity@Sun.COM (fatcity) writes:
>< 	do i = 1, max
>< 	   read(ilun,'(your format)',IOSTAT=istat) your variable list
>< 	   if (istat .EQ. EOF) then
>< 		 EXIT
>< 	   else if (istat .NE. OK) then
>< 	         call abort('your favorite abort messages',istat)
>< 	   endif
>< 	   your processing goes here
>< 	end do
>
>Nice idea, but isn't it kind of environment dependent?  Like, where does the
>value of the EOF parameter come from?

A good point.  To make it environment-independent, change the condition

	if (istat .EQ. EOF) then

to read

	if (istat .LT. 0) then

which is guaranteed to be .TRUE. if and only if an end-of-file condition
was encountered on the preceding read, because of paragraph 12.7 in the 
standard.  By the same token, the condition

	else if (istat .NE. OK) then

would be better expressed as

	else if (istat .GT. 0) then

for detecting error conditions.  This also demonstrates why end-of-file is
definitely not an error condition:  the IOSTAT= return would have to be
simultaneously positive and negative!

-- 
Dave Seaman	  					
ags@j.cc.purdue.edu

davies@uicsrd.csrd.uiuc.edu (03/02/89)

The standard leaves the values of iostat undefined, but it does require
that the value returned is negative for end-of-file, zero if the read
succeeds, and greater than zero if there was an error.  You should be
able to just test for zero to see if the read succeeded, if you don't
care why it failed.  (Of course, the original note was complaining that
he had to give both err= and end=. Adding another statement to test the
iostat can only be worse.)

khb@fatcity.Sun.COM (fatcity) (03/02/89)

In article <3836@s.cc.purdue.edu> ags@s.cc.purdue.edu (Dave Seaman) writes:
>In article <3234@ttrdc.UUCP> levy@ttrdc.UUCP (Daniel R. Levy) writes:
>>In article <91480@sun.uucp>, khb%fatcity@Sun.COM (fatcity) writes:
>>< 	do i = 1, max
>>< 	   read(ilun,'(your format)',IOSTAT=istat) your variable list
>>< 	   if (istat .EQ. EOF) then
>>< 		 EXIT
>>< 	   else if (istat .NE. OK) then
>>< 	         call abort('your favorite abort messages',istat)
>>< 	   endif
>>< 	   your processing goes here
>>< 	end do
>>
>>Nice idea, but isn't it kind of environment dependent?  Like, where does the
>>value of the EOF parameter come from?
>
>A good point.  To make it environment-independent, change the condition
>
>	if (istat .EQ. EOF) then
>
>to read
>
>	if (istat .LT. 0) then
>

I neglected to save a copy of my original posting, but I beleive that
I pointed out that the constants had to be defined. If one wishes to
remain totally ansi compliant (no includes), yet have the codes be in
exactly one place


	INTEGER EOF
	COMMON /IOSTUF/ EOF, etc.

and a block common used to define the machine values.

Dave is right, one can use the numerical values directly....but I find
that it is easier to read, and maintain code with the suggested
symbolic substitution.

If one allows macros (as found in all POSIX compliant systems, and
many wanna be's)  

#include "iostuff"

And there you have it.

Cheers, all.
Keith H. Bierman
It's Not My Fault ---- I Voted for Bill & Opus

ags@s.cc.purdue.edu (Dave Seaman) (03/02/89)

In article <91960@sun.uucp> khb@sun.UUCP (fatcity) writes:
>I neglected to save a copy of my original posting, but I beleive that
>I pointed out that the constants had to be defined. If one wishes to
>remain totally ansi compliant (no includes), yet have the codes be in
>exactly one place
>
>
>	INTEGER EOF
>	COMMON /IOSTUF/ EOF, etc.
>
>and a block common used to define the machine values.

You missed my point.  The fact that you have all your machine-dependent code
gathered in one place does not make it less machine-dependent.  The ANSI
standard guarantees that an end-of-file condition exists if and only if the
IOSTAT return is negative, and an error condition exists if and only if the
IOSTAT return is positive.  The standard does not say what the actual value is
required to be.  If you prefer to see disguised constants, then by all means
use:

	INTEGER OK
	PARAMETER (OK=0)
	. . .
	READ (5,10,IOSTAT=ISTAT) X,Y,Z
	IF (ISTAT .LT. OK) THEN
	  . . . handle the EOF condition
	ELSE IF (ISTAT .GT. OK) THEN
	  . . . handle the error condition
	ENDIF

The point is that this code runs on any standard-conforming processor
without change.

-- 
Dave Seaman	  					
ags@j.cc.purdue.edu