forums.silverfrost.com

[DanRRight]

I'd look also how IVF treats that.

[JohnCampbell]

Intel Fortran has IOSTAT=63 condition, which relates to this problem, although I have never seen it occur.
I am not sure how it would work, or how to select between "error or info"
The following is an extract taken from Intel's List of Run-Time Error Messages.
https://software.intel.com/en-us/node/525375

[DanRRight]

Anyone has IVF to run the code on message 1? The Silverfrost developers simply MUST have it.

But let's return to this issue after /64 will be ready, it is of 1/10000000 the importance

[simon]

I think John's suggestion of setting an IOSTAT condition for this problem would be favourite. To me it seems important that the compiler should behave in a consistent manner as follows:

1. If ERR and IOSTAT are absent, the program terminates if there is an IO error

2. If ERR is present the program jumps to the line label regardless of the error

3. If IOSTAT is present the program continues regardless and the programmer decides what if anything to do.

So if we define

[mecej4]

Simon,

It is good to see someone think through the ramifications of a suggested change to the compiler. In the present instance, Paul has made it clear that the extension, which is not in conformity with the standard, will apply only when it is chosen through a deliberate subroutine call. As long as most users are shielded from such non-standard behavior, one cannot complain about its being provided, apart from observing that I as a user would rather see Silverfrost direct its development efforts to issues that relate to unimplemented features of the standard (such as those in TR-15581), 64 bit code, etc.

I see this problem with your description in Item 2.: If ERR is present the program jumps to the line label regardless of the error. The very abbreviation ERR implies association with an error, and the standard itself says the following in 9.11.5 regarding IOSTAT:

1 Execution of an input/output statement containing the IOSTAT= specifier causes the scalar-int-variable in the IOSTAT= specifier to become defined with a zero value if neither an error condition, an end-of-file condition, nor an end-of-record condition occurs,...

Thus, we are faced with a number of inconsistencies when the proposed non-standard extension is active:

1. An error is not an error if you don't check for it.
2. You cannot compare IOSTAT to zero to decide whether an error occurred.
3. ... many other inconsistencies that will be revealed only after extensive investigation and/or experience.