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