Fortran CVF 6.5 bug? 
Author Message
 Fortran CVF 6.5 bug?

A colleague pointed this out.  Is this a known CVF 6.5 bug?

I find that the following causes a fatal error in 6.5 while it all worked
fine in 6.1

Try:

READ (unit=12, err=999) dummystring

!  End of file found
999   continue

When this reaches the end of file on Unit 12, instead of going to 999 it
crashes. Fix is the following first line:

READ (unit=12, err=999,end=999) dummystring

Adrian



Fri, 07 Nov 2003 22:48:35 GMT  
 Fortran CVF 6.5 bug?
On Mon, 21 May 2001 09:48:35 -0500, "Adrian Ferramosca"

Quote:

>A colleague pointed this out.  Is this a known CVF 6.5 bug?

>I find that the following causes a fatal error in 6.5 while it all worked
>fine in 6.1

>Try:

>READ (unit=12, err=999) dummystring

>!  End of file found
>999   continue

>When this reaches the end of file on Unit 12, instead of going to 999 it
>crashes. Fix is the following first line:

>READ (unit=12, err=999,end=999) dummystring

It's a bug in 6.1  that 6.5 fixed, and is explained in the Release
Notes:

               - In order to conform with clarified wording in the
                 fortran standard, the compiler has been changed so
                 that when a READ statement encounters an end-of-file
                 condition, and there is no END= specifier but there
                 is an ERR= specifier, the ERR= branch is NOT taken.
                 Similarly, if an end-of-record condition occurs but
                 there is no EOR= specifier, an ERR= branch is not
                 taken.

                 A further behavior change, to conform with the
                 standard, has been implemented. If an EOF (or EOR)
                 condition occurs and there is not an IOSTAT= or END=
                 (or EOR=  in the case of EOR) specifier, the program
                 is terminated with an error message.



Fortran Engineering
Compaq Computer Corporation, Nashua NH

Compaq Fortran web site: http://www.compaq.com/fortran
Message Board: http://www.compaq.com/fortran/forum



Fri, 07 Nov 2003 23:38:22 GMT  
 Fortran CVF 6.5 bug?


Quote:
>On Mon, 21 May 2001 09:48:35 -0500, "Adrian Ferramosca"

>>A colleague pointed this out.  Is this a known CVF 6.5 bug?

>>I find that the following causes a fatal error in 6.5 while it all worked
>>fine in 6.1

>>Try:

>>READ (unit=12, err=999) dummystring

>>!  End of file found
>>999   continue

>>When this reaches the end of file on Unit 12, instead of going to 999 it
>>crashes. Fix is the following first line:

>>READ (unit=12, err=999,end=999) dummystring

>It's a bug in 6.1  that 6.5 fixed, and is explained in the Release
>Notes:

>               - In order to conform with clarified wording in the
>                 Fortran standard, the compiler has been changed so
>                 that when a READ statement encounters an end-of-file
>                 condition, and there is no END= specifier but there
>                 is an ERR= specifier, the ERR= branch is NOT taken.
>                 Similarly, if an end-of-record condition occurs but
>                 there is no EOR= specifier, an ERR= branch is not
>                 taken.

>                 A further behavior change, to conform with the
>                 standard, has been implemented. If an EOF (or EOR)
>                 condition occurs and there is not an IOSTAT= or END=
>                 (or EOR=  in the case of EOR) specifier, the program
>                 is terminated with an error message.



>Fortran Engineering
>Compaq Computer Corporation, Nashua NH

>Compaq Fortran web site: http://www.compaq.com/fortran
>Message Board: http://www.compaq.com/fortran/forum

I am interested in knowing what changed in the standard.
Section 9.4.3 still states

     The set of input/output error conditions is processor
     dependent.

J3 has stated that that clause allows an implementor carte
blanche when deciding what constitutes an input/output
error condition.  I assume that includes allowing an
implementation to take the presence or absence of an END=
or ERR= specifier into account.

I assume that, because you are not treating reading an
end-of-file record as an error condition, you are really
giving an end-of-file message before terminating execution,
not an error message.

                                        Sincerely,
                                        Bob Corbett



Sat, 08 Nov 2003 02:09:46 GMT  
 Fortran CVF 6.5 bug?

Quote:

> A colleague pointed this out.  Is this a known CVF 6.5 bug?
...
> READ (unit=12, err=999) dummystring
...
> When this reaches the end of file on Unit 12, instead of going to 999 it
> crashes.

That would be a known program bug.  End-of-file is not the same thing as
an error.  You should expect a crash in this case.  *FAILING* to
crash would be a compiler bug.  I.e. it is the earlier version of CVF
that had a bug, and this code was apparently depending on that bug.

--
Richard Maine                       |  Good judgment comes from experience;
email: my last name at host.domain  |  experience comes from bad judgment.
host: altair, domain: dfrc.nasa.gov |        -- Mark Twain



Sat, 08 Nov 2003 02:39:58 GMT  
 Fortran CVF 6.5 bug?


Quote:
>I am interested in knowing what changed in the standard.
>Section 9.4.3 still states

>     The set of input/output error conditions is processor
>     dependent.

>J3 has stated that that clause allows an implementor carte
>blanche when deciding what constitutes an input/output
>error condition.  I assume that includes allowing an
>implementation to take the presence or absence of an END=
>or ERR= specifier into account.

>I assume that, because you are not treating reading an
>end-of-file record as an error condition, you are really
>giving an end-of-file message before terminating execution,
>not an error message.

Well, J3 doesn't talk to me (not directly), but my J3 rep (Stan
Whitlock) does, and he agreed that the F95 standard is unambiguous
about this.  While the "set of error conditions" may be processor
dependent, the standard does not consider EOF and EOR to be "error
conditions" (if it did, the title of 9.4.3 wouldn't be "Error,
end-of-record, and end-of-file conditions".)

9.4.3 (page 150, lines 19-23) says:

"Execution of the program is terminated if an error condition occurs
during execution of an input/output statement that contains neither an
IOSTAT= nor an ERR= specifier, or if an end-of-file condition occurs
during execution of a READ statement that contains neither an IOSTAT=
specifier nor and END= specifier, or if an end-of-record condition
occurs during the execution of a nonadvancing READ statement that
contains neither an IOSTAT= specifier nor an EOR= specifier."

F90 contains the same language, and F77 contains essentially the same
language, minus the EOR behavior, of course.  Our bug, which we've had
in our compilers for many years, was to treat end-of-file as an "error
condition", even though the standard says that it is not.

That said, we have decided not to change our F77 compilers to reflect
this.


Fortran Engineering
Compaq Computer Corporation, Nashua NH

Compaq Fortran web site: http://www.compaq.com/fortran



Sat, 08 Nov 2003 03:07:23 GMT  
 Fortran CVF 6.5 bug?


Quote:

>Well, J3 doesn't talk to me (not directly), but my J3 rep (Stan
>Whitlock) does, and he agreed that the F95 standard is unambiguous
>about this.  While the "set of error conditions" may be processor
>dependent, the standard does not consider EOF and EOR to be "error
>conditions" (if it did, the title of 9.4.3 wouldn't be "Error,
>end-of-record, and end-of-file conditions".)

>9.4.3 (page 150, lines 19-23) says:

>"Execution of the program is terminated if an error condition occurs
>during execution of an input/output statement that contains neither an
>IOSTAT= nor an ERR= specifier, or if an end-of-file condition occurs
>during execution of a READ statement that contains neither an IOSTAT=
>specifier nor and END= specifier, or if an end-of-record condition
>occurs during the execution of a nonadvancing READ statement that
>contains neither an IOSTAT= specifier nor an EOR= specifier."

>F90 contains the same language, and F77 contains essentially the same
>language, minus the EOR behavior, of course.  Our bug, which we've had
>in our compilers for many years, was to treat end-of-file as an "error
>condition", even though the standard says that it is not.

I'm sorry, but I still believe that the way your f77 treats
reading an end-of-file record is allowed by the standard.
I agree that an end-of-file condition is not the same as an
error condition.  I see nothing in the standard that prohibits
an implementation from treating reading an end-of-file record
using a READ statement that includes an ERR= specifier but not
an END= specifier as an error condition.

BTW, Sun made the same change in its f90 product, but Sun made
the change because of customer requests, not because of any
perceived violation of the Fortran standard.

                                        Sincerely,
                                        Bob Corbett



Sat, 08 Nov 2003 05:24:39 GMT  
 Fortran CVF 6.5 bug?

Quote:



>>Our bug, which we've had
>>in our compilers for many years, was to treat end-of-file as an "error
>>condition", even though the standard says that it is not.

>I'm sorry, but I still believe that the way your f77 treats
>reading an end-of-file record is allowed by the standard.

Hmm. Let's see what the f77 standard itself says. I suppose one might
force end-of-file to be treated as an error condition by appealing
to Section 12.6 where it says

          The set of input/output error conditions  is  processor
          dependent.

However Section 12.7 says, on IOSTAT = ios,

          Execution of an input/output statement containing  this
          specifier causes ios to become defined:

          ...(3) with  a  processor-dependent  negative   integer
                 value if an end-of-file condition is encountered
                 and no error condition is encountered.

which suggests that processors should not treat end-of-file as a
special case of error, and so does section 12.7.2 saying

          If a READ statement contains an  end-of-file  specifier
          and  the  processor encounters an end-of-file condition
          and  no  error  condition  during  execution   of   the
          statement: ...

If end-of-file occurs when there is an ERR = but neither IOSTAT =
nor END = then the last part of Section 12.6 seems to apply:

                                ... 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.

John Harper, School of Mathematical and Computing Sciences,
Victoria University, Wellington, New Zealand



Sun, 09 Nov 2003 05:26:19 GMT  
 Fortran CVF 6.5 bug?

Quote:


> > A colleague pointed this out.  Is this a known CVF 6.5 bug?
> ...
> > READ (unit=12, err=999) dummystring
> ...
> > When this reaches the end of file on Unit 12, instead of going to 999 it
> > crashes.

> That would be a known program bug.  End-of-file is not the same thing as
> an error.  You should expect a crash in this case.

Thanks for such a succinct illustration of the silliness of the
standard in this regard.  The program must crash because end-of-file
is not an error.




Wed, 12 Nov 2003 12:13:03 GMT  
 Fortran CVF 6.5 bug?

Quote:


> > > READ (unit=12, err=999) dummystring
> > > When this reaches the end of file on Unit 12, instead of going to 999 it
> > > crashes.
> > That would be a known program bug.  End-of-file is not the same thing as
> > an error.  You should expect a crash in this case.
> Thanks for such a succinct illustration of the silliness of the
> standard in this regard.  The program must crash because end-of-file
> is not an error.

The sole purpose of ERR, END, EOR, and IOS in I/O statements is to enable a
recovery action more "intelligent" than the default "this happened, but as it
seems unlikely your program will continue to do anything useful, I'll rather
terminate it", with the "I" being the author of the run-time support of the
compiler in question.

Now, you may quibble with the Fortran standard's subdivision of the applicable
exceptional conditions into "end of record", "end of file", and "everything
else, and the error value is system-specific", but it's better than nothing,
and certainly makes the two very common conditions for which coding a recovery
is fairly easy (EOR and EOF) portable. But to work, the subdivision _must_ be
orthogonal - that is, EOR and EOF must be _excluded_ from ERR.

You may, however, complain to the committee, ANSI, ISO and compiler vendors
that they didn't have a sufficiently clear view of the issue to put it in
such clear words (slaps himself on the back) - neither in the documentation
accompanying the compiler(s) nor in the standard text, requiring as it did an
(apparently controversial, still) interpretation of the standard - but that
is quite a seperate issue.

        Jan



Sat, 15 Nov 2003 21:58:44 GMT  
 
 [ 9 post ] 

 Relevant Pages 

1. Visual Basic cannot find Fortran DLL CVF 6.5

2. CVF Upgrade from 6.5 to 6.6 and DWINTY.F90

3. CVF 6.5, specific question about minimization subroutine dbconf

4. Internal Compiler Error (C0000005)-CVF 6.5

5. CVF 6.5: Profiling trouble

6. Test_Fpu 2ghz pentium/CVF 6.5

7. How to use Array Visualizer in CVF 6.5

8. Question about CVF 6.5 and Developer Studio -New directories

9. Two questions re: CVF 6.5

10. CVF 6.5 problem

11. mixed language problem - CVF 6.5 - MS Visual C++ 6 (DEC$ ATTRIBUTES C, EXTERN)

 

 
Powered by phpBB® Forum Software