12.11.5 IOSTAT= specifier
1 Execution of an input/output statement containing the IOSTAT= specifier causes the stat-variable in the ISTAT= 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,
• the processor-dependent positive integer value of the constant IOSTAT_INQUIRE_INTERNAL_UNIT from the intrinsic module ISO_FORTRAN_ENV (16.10.2) if a unit number in an INQUIRE statement identifies an internal file,
• a processor-dependent positive integer value different from IOSTAT_INQUIRE_INTERNAL_UNIT if any other error condition occurs,
• the processor-dependent negative integer value of the constant IOSTAT_END (16.10.2.16) from the intrinsic module ISO_FORTRAN_ENV if an end-of-file condition occurs and no error condition occurs,

On Tuesday, July 26, 2022 at 1:33:04 AM UTC+10, Ron Shepard wrote:
> On 7/25/22 1:03 AM, Robin Vowels wrote:
> > The situation is NOT "processor dependent". The actual numerical value
> > is processor dependent", but the sign of the value is NOT. The sign
> > is required to be positive. ifort is not standard-conforming.
..
> Can you quote the standard, any version of the standard, that specifies
> this?
..
ANSI X3.9-1978 Programming Language FORTRAN.
..
12.7

IOSTAT = ios

where ios is an integer variable or integer array element.

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

(1) with a zero value if neither an error condition nor
an end-of-file condition is encountered by the processor.

(2) with a processor-dependent positive integer value if an
error condition is encountered, or

(3) with a processor-dependent negative integer value if
an end-of-file condition is encountered and no error
condition is encountered.
..
> I do not think it is true for the reasons I explained previously
> in this thread. If this were true, then there would be no way to read
> multiple files from a magnetic tape. Yet at one time, that was a
> routine, everyday, occurrence for fortran programmers.

On Monday, July 25, 2022 at 8:33:04 AM UTC-7, Ron Shepard wrote:
> On 7/25/22 1:03 AM, Robin Vowels wrote:
> > The situation is NOT "processor dependent". The actual numerical value
> > is processor dependent", but the sign of the value is NOT. The sign
> > is required to be positive. ifort is not standard-conforming.

> Can you quote the standard, any version of the standard, that specifies
> this? I do not think it is true for the reasons I explained previously
> in this thread. If this were true, then there would be no way to read
> multiple files from a magnetic tape. Yet at one time, that was a
> routine, everyday, occurrence for fortran programmers.

Fortran 66, the version used when tapes were most popular, has no way
to detect EOF or ERR.

The END= and ERR= options, as well as I know, where added to IBM
Fortran IV, as extensions to Fortran 66. (Or maybe earlier, but that didn't
make it into the standard.) IBM is always good at marking the extensions
in their manual with a gray shading.

With OS/360 Fortran compilers, you use a DD statement in JCL for each
tape (or non-tape) file you want to read. It will first read from DDname
FTxxF001, where xx is the unit number. After the EOF exit, continued
reading is from FTxxF002. You can read many different disk data sets,
or sequential (or any order) tape data sets, with appropriate JCL.
For tapes, you need LABEL=(1,SL) for the first file on a standard
labelled tape (where the DSNAME must agree), and LABEL=(2,SL)
for the next one.

Or LABEL=(1,NL) for an unlabelled tape, or LABEL=(1,AL) for an
ANSI labelled tape. The latter worked with VAX, and also did
EBCDIC to/from ASCII translation.

So, the error case occurs when it tries to read a file that isn't
there, after the END= case. As well as I know, the standard
doesn't require that ability, but does allow for it.

Or it could immediately give END= for the (non-existent)
next file.

In any case, when IOSTAT is non-zero, either sign, the
standard makes all variables in the I/O list undefined.
Even the ones that might have been read before the
EOF or ERR condition.

On 7/25/2022 2:03 AM, Robin Vowels wrote:
>>>>> The closest anyone has come is Steve Lionel, who said he could
>>>>> make an argument for the second instance not being -1, but he didn't
>>>>> present that argument. That ifort returns -1 upon a second READ
>>>>> demonstrates that the situation is "processor dependent".
> The situation is NOT "processor dependent". The actual numerical value
> is processor dependent", but the sign of the value is NOT. The sign
> is required to be positive. ifort is not standard-conforming.
>

I discussed this issue with Malcolm Cohen of NAG last week. He agreed
with me that continuing to read after the "ENDFILE record" has been
passed is an error, and NOT an end-of-file condition, therefore a
positive IOSTAT value is required. ifort is wrong here.

Note that you can BACKSPACE back to before the "ENDFILE record" (which
doesn't have to have a physical manifestation), and then get an endfile
condition again on a subsequent read.

While it was once common practice to read past tapemarks on unlabeled
magnetic tapes, that never became part of the Fortran standard.
--
Steve Lionel
ISO/IEC JTC1/SC22/WG5 (Fortran) Convenor
Retired Intel Fortran developer/support
Email: firstname at firstnamelastname dot com
Twitter: @DoctorFortran
LinkedIn: https://www.linkedin.com/in/stevelionel
Blog: https://stevelionel.com/drfortran
WG5: https://wg5-fortran.org

On Monday, July 25, 2022 at 11:57:52 AM UTC-7, Steve Lionel wrote:
> On 7/25/2022 2:03 AM, Robin Vowels wrote:
> >>>>> The closest anyone has come is Steve Lionel, who said he could
> >>>>> make an argument for the second instance not being -1, but he didn't
> >>>>> present that argument. That ifort returns -1 upon a second READ
> >>>>> demonstrates that the situation is "processor dependent".
> > The situation is NOT "processor dependent". The actual numerical value
> > is processor dependent", but the sign of the value is NOT. The sign
> > is required to be positive. ifort is not standard-conforming.
> >
> I discussed this issue with Malcolm Cohen of NAG last week. He agreed
> with me that continuing to read after the "ENDFILE record" has been
> passed is an error, and NOT an end-of-file condition, therefore a
> positive IOSTAT value is required. ifort is wrong here.
>
> Note that you can BACKSPACE back to before the "ENDFILE record" (which
> doesn't have to have a physical manifestation), and then get an endfile
> condition again on a subsequent read.
>
> While it was once common practice to read past tapemarks on unlabeled
> magnetic tapes, that never became part of the Fortran standard.
> --
> Steve Lionel
> ISO/IEC JTC1/SC22/WG5 (Fortran) Convenor
> Retired Intel Fortran developer/support
> Email: firstname at firstnamelastname dot com
> Twitter: @DoctorFortran
> LinkedIn: https://www.linkedin.com/in/stevelionel
> Blog: https://stevelionel.com/drfortran
> WG5: https://wg5-fortran.org

I agree with you that attempting to read past the
endfile record of a sequential-access file is an
error, not an end-of-file condition. I do not agree
that it necessarily is an input/output error
condition. Subclause 12.11.1 of the Fortran 2018
standard states

The set of input/output error conditions is
processor dependent. Except as otherwise
specified, when an error condition occurs or
is detected is processor dependent.

Paragraph 2 of subclause 12.3.4.3 states

Input shall not occur if there is no next
record or if there is a current record and
the last data transfer statement accessing
the file performed output.

Nothing in that statement specifies that an
error condition occurs. It only says that a
program that tries to read a record that does
not exist is not a conforming program.

The Fortran standard explicitly does not
specify the behavior of programs that are
not standard conforming (see item 4 in the
list given in paragraph 4 of clause 1).
Therefore, a program that tries to read past
the end of the file could detect an
input/output error condition. It could detect
an end-of-file condition. It could detect an
end-of-record condition. It could read a record
from some other file.

There was once a proposal to codify the set of
input/output error conditions, but the effort did
not last long.

An attempt to read after an end-of-file
condition has occurred leads to unspecified
behavior.

On Monday, July 25, 2022 at 2:40:03 PM UTC-7, Robert Corbett wrote:
> On Monday, July 25, 2022 at 11:57:52 AM UTC-7, Steve Lionel wrote:

(snip)
> > While it was once common practice to read past tapemarks on unlabeled
> > magnetic tapes, that never became part of the Fortran standard.

(snip)
> I agree with you that attempting to read past the
> endfile record of a sequential-access file is an
> error, not an end-of-file condition. I do not agree
> that it necessarily is an input/output error
> condition. Subclause 12.11.1 of the Fortran 2018
> standard states

(snip)
> Input shall not occur if there is no next
> record or if there is a current record and
> the last data transfer statement accessing
> the file performed output.
> Nothing in that statement specifies that an
> error condition occurs. It only says that a
> program that tries to read a record that does
> not exist is not a conforming program.
> The Fortran standard explicitly does not
> specify the behavior of programs that are
> not standard conforming (see item 4 in the
> list given in paragraph 4 of clause 1).
> Therefore, a program that tries to read past
> the end of the file could detect an
> input/output error condition. It could detect
> an end-of-file condition. It could detect an
> end-of-record condition. It could read a record
> from some other file.
Unix/C allows, and I presume is part of POSIX,
for a program to continue reading in case a file
size increases.

Specifically, that is used by the "tail -f" command
to follow writing to a file.

That is complicated by systems that do file locking,
but it works fine with Unix.

I am not so sure about the connection between
Fortran and POSIX.

On 7/25/22 1:57 PM, Steve Lionel wrote:
> While it was once common practice to read past tapemarks on unlabeled
> magnetic tapes, that never became part of the Fortran standard.

I agree that fortran does not require this behavior, but I think the
current question is asking the other way. Did any Fortran standard ever
forbid it from occurring? I don't think it did, I think it left it as
processor dependent to first detect it as an error, and second which
positive error code to report if it was detected as an error. Doing this
makes sense for some devices, like magnetic tapes with multiple files,
or card decks with end-of-deck cards interspersed, but not others, like
a disk file system.

$.02 -Ron Shepard

On 7/25/22 11:25 AM, Robin Vowels wrote:
> On Tuesday, July 26, 2022 at 1:33:04 AM UTC+10, Ron Shepard wrote:
>> On 7/25/22 1:03 AM, Robin Vowels wrote:
>>> The situation is NOT "processor dependent". The actual numerical value
>>> is processor dependent", but the sign of the value is NOT. The sign
>>> is required to be positive. ifort is not standard-conforming.
> .
>> Can you quote the standard, any version of the standard, that specifies
>> this?
> .
> ANSI X3.9-1978 Programming Language FORTRAN.
> .
> 12.7
>
> IOSTAT = ios
>
> where ios is an integer variable or integer array element.
>
> Execution of an input/output statement statement containing
> this specifier causes ios to become defined:
>
> (1) with a zero value if neither an error condition nor
> an end-of-file condition is encountered by the processor.
>
> (2) with a processor-dependent positive integer value if an
> error condition is encountered, or

This only occurs "if an error condition is encountered". The f77
standard does not specify that reading past an EOF marker is an error
condition. Neither does it specify that it is not an error condition.

$.02 -Ron Shepard

On Tuesday, July 26, 2022 at 6:21:31 PM UTC+10, Ron Shepard wrote:
> On 7/25/22 11:25 AM, Robin Vowels wrote:
> > On Tuesday, July 26, 2022 at 1:33:04 AM UTC+10, Ron Shepard wrote:
> >> On 7/25/22 1:03 AM, Robin Vowels wrote:
> >>> The situation is NOT "processor dependent". The actual numerical value
> >>> is processor dependent", but the sign of the value is NOT. The sign
> >>> is required to be positive. ifort is not standard-conforming.
> > .
> >> Can you quote the standard, any version of the standard, that specifies
> >> this?
> > .
> > ANSI X3.9-1978 Programming Language FORTRAN.
> > .
> > 12.7
> >
> > IOSTAT = ios
> >
> > where ios is an integer variable or integer array element.
> >
> > Execution of an input/output statement statement containing
> > this specifier causes ios to become defined:
> >
> > (1) with a zero value if neither an error condition nor
> > an end-of-file condition is encountered by the processor.
> >
> > (2) with a processor-dependent positive integer value if an
> > error condition is encountered, or
..
> This only occurs "if an error condition is encountered". The f77
> standard does not specify that reading past an EOF marker is an error
> condition. Neither does it specify that it is not an error condition.
..
The F77 and subsequent standards specify two kinds of things:
1. an end-of-file condition;
2. an error condition.
If the event is not an end-of-file condition, it is therefore an error condition.
It is clear and unequivocal.

On Tuesday, July 26, 2022 at 4:04:19 AM UTC+10, gah4 wrote:
..
> Fortran 66, the version used when tapes were most popular, has no way
> to detect EOF or ERR.
>
> The END= and ERR= options, as well as I know, where added to IBM
> Fortran IV, as extensions to Fortran 66. (Or maybe earlier, but that didn't
> make it into the standard.) IBM is always good at marking the extensions
> in their manual with a gray shading.

A good reason for using PL/I which, in 1966, treated routinely
end-of-file conditions [ ON ENDFILE (x) ... ] and error conditions
[ ON ERROR ... ]

> With OS/360 Fortran compilers, you use a DD statement in JCL for each
> tape (or non-tape) file you want to read. It will first read from DDname
> FTxxF001, where xx is the unit number. After the EOF exit, continued
> reading is from FTxxF002. You can read many different disk data sets,
> or sequential (or any order) tape data sets, with appropriate JCL.
> For tapes, you need LABEL=(1,SL) for the first file on a standard
> labelled tape (where the DSNAME must agree), and LABEL=(2,SL)
> for the next one.
>
> Or LABEL=(1,NL) for an unlabelled tape, or LABEL=(1,AL) for an
> ANSI labelled tape. The latter worked with VAX, and also did
> EBCDIC to/from ASCII translation.
>
> So, the error case occurs when it tries to read a file that isn't
> there, after the END= case. As well as I know, the standard
> doesn't require that ability, but does allow for it.
>
> Or it could immediately give END= for the (non-existent)
> next file.
>
> In any case, when IOSTAT is non-zero, either sign, the
> standard makes all variables in the I/O list undefined.
> Even the ones that might have been read before the
> EOF or ERR condition.
..
Another reason for using PL/I, in which variables already read
were stored, and the values of which were available.
..
FORTRAN did not have any of those facilities until more
than a decade later.

On Tuesday, July 26, 2022 at 1:10:44 AM UTC-7, Ron Shepard wrote:
> On 7/25/22 1:57 PM, Steve Lionel wrote:
> > While it was once common practice to read past tapemarks on unlabeled
> > magnetic tapes, that never became part of the Fortran standard.

> I agree that fortran does not require this behavior, but I think the
> current question is asking the other way. Did any Fortran standard ever
> forbid it from occurring? I don't think it did, I think it left it as
> processor dependent to first detect it as an error, and second which
> positive error code to report if it was detected as an error. Doing this
> makes sense for some devices, like magnetic tapes with multiple files,
> or card decks with end-of-deck cards interspersed, but not others, like
> a disk file system.
As I note, with OS/360 Fortran you can have a different disk dataset
to be read after each EOF, with a different DD card. It did always
seem a strange system, as reading sequential files on a tape
seems more obvious.

On 7/26/2022 4:10 AM, Ron Shepard wrote:
> On 7/25/22 1:57 PM, Steve Lionel wrote:
>> While it was once common practice to read past tapemarks on unlabeled
>> magnetic tapes, that never became part of the Fortran standard.
>
> I agree that fortran does not require this behavior, but I think the
> current question is asking the other way. Did any Fortran standard ever
> forbid it from occurring?

The Fortran standard isn't written that way - it describes a
standard-conforming program and what such a program is supposed to do. A
program that is written or behaves in a manner not specified by the
standard is non-conforming and its behavior is processor-dependent.

MIL-STD-1753 did specify that a read after EOF was permissible, but that
aspect never made it into the Fortran standard.
--
Steve Lionel
ISO/IEC JTC1/SC22/WG5 (Fortran) Convenor
Retired Intel Fortran developer/support
Email: firstname at firstnamelastname dot com
Twitter: @DoctorFortran
LinkedIn: https://www.linkedin.com/in/stevelionel
Blog: https://stevelionel.com/drfortran
WG5: https://wg5-fortran.org

On 7/26/22 5:29 AM, Robin Vowels wrote:
> On Tuesday, July 26, 2022 at 6:21:31 PM UTC+10, Ron Shepard wrote:
[...]
>>> Execution of an input/output statement statement containing
>>> this specifier causes ios to become defined:
>>>
>>> (1) with a zero value if neither an error condition nor
>>> an end-of-file condition is encountered by the processor.
>>>
>>> (2) with a processor-dependent positive integer value if an
>>> error condition is encountered, or
> .
>> This only occurs "if an error condition is encountered". The f77
>> standard does not specify that reading past an EOF marker is an error
>> condition. Neither does it specify that it is not an error condition.
> .
> The F77 and subsequent standards specify two kinds of things:
> 1. an end-of-file condition;
> 2. an error condition.
> If the event is not an end-of-file condition, it is therefore an error condition.
> It is clear and unequivocal.

Show in the text where these are the only two choices when an end of
file is encountered. I don't think it does, I think it leaves it
unspecified, and I think it did so purposefully in order to allow, but
not require, reading more than one file from a tape, card deck, etc.

$.02 -Ron Shepard

On 7/26/22 5:36 AM, Robin Vowels wrote:
[...]

> A good reason for using PL/I which, in 1966, treated routinely
> end-of-file conditions [ ON ENDFILE (x) ... ] and error conditions
> [ ON ERROR ... ]

Just out of curiosity, would PL/I allow a programmer to read multiple
files from a magnetic tape. separated by end-of-file records, or to read
multiple files from a card deck that had end-of-deck cards interspersed
in the stack?

$.02 -Ron Shepard

On 7/26/22 7:03 AM, gah4 wrote:
> On Tuesday, July 26, 2022 at 1:10:44 AM UTC-7, Ron Shepard wrote:
>> On 7/25/22 1:57 PM, Steve Lionel wrote:
>>> While it was once common practice to read past tapemarks on unlabeled
>>> magnetic tapes, that never became part of the Fortran standard.
>
>> I agree that fortran does not require this behavior, but I think the
>> current question is asking the other way. Did any Fortran standard ever
>> forbid it from occurring? I don't think it did, I think it left it as
>> processor dependent to first detect it as an error, and second which
>> positive error code to report if it was detected as an error. Doing this
>> makes sense for some devices, like magnetic tapes with multiple files,
>> or card decks with end-of-deck cards interspersed, but not others, like
>> a disk file system.
>
> As I note, with OS/360 Fortran you can have a different disk dataset
> to be read after each EOF, with a different DD card. It did always
> seem a strange system, as reading sequential files on a tape
> seems more obvious.

Yes, I agree, I was too generous with that example, I should have said
that "some disk file systems" do not allow it.

Regarding unix/POSIX disk file systems, it is required that utilities
like "tail -f" and "more" should be able to read files that are in the
process of being written. Those files do not really have an end-of-file
record, the end is determined by a file system parameter. When the file
pointer reaches that value, the utility sleeps and then wakes up and
checks again to see if more data has been written. So the underlying
model is different from a series of files written to magnetic tape. I'm
not certain, but I don't think "tail -f" or "more" would be required to
work that way on an actual magnetic tape device.

$.02 -Ron Shepard

On 7/26/2022 3:10 AM, Ron Shepard wrote:
> On 7/25/22 1:57 PM, Steve Lionel wrote:
>> While it was once common practice to read past tapemarks on unlabeled
>> magnetic tapes, that never became part of the Fortran standard.
>
> I agree that fortran does not require this behavior, but I think the
> current question is asking the other way. Did any Fortran standard ever
> forbid it from occurring? I don't think it did, I think it left it as
> processor dependent to first detect it as an error, and second which
> positive error code to report if it was detected as an error. Doing this
> makes sense for some devices, like magnetic tapes with multiple files,
> or card decks with end-of-deck cards interspersed, but not others, like
> a disk file system.
>

Some OS' of the past supported multiple files on disk as well and
returned EOF followed by EOT for disk files with only one file.

> $.02 -Ron Shepard
>

On 7/26/22 7:04 AM, Steve Lionel wrote:
> On 7/26/2022 4:10 AM, Ron Shepard wrote:
>> On 7/25/22 1:57 PM, Steve Lionel wrote:
>>> While it was once common practice to read past tapemarks on unlabeled
>>> magnetic tapes, that never became part of the Fortran standard.
>>
>> I agree that fortran does not require this behavior, but I think the
>> current question is asking the other way. Did any Fortran standard
>> ever forbid it from occurring?
>
> The Fortran standard isn't written that way - it describes a
> standard-conforming program and what such a program is supposed to do. A
> program that is written or behaves in a manner not specified by the
> standard is non-conforming and its behavior is processor-dependent.
>
> MIL-STD-1753 did specify that a read after EOF was permissible, but that
> aspect never made it into the Fortran standard.

This is the sometimes subtle distinction between a nonconforming program
that violates some aspect of the standard and one that is rather
unspecified by the standard. My question regarding reading past an end
of file marker was exactly that point. I think the fortran standard (in
contrast to the MIL-STD standard) never specified that behavior one way
or the other. Others in this discussion are claiming that it was
specifically forbidden and that positive IOSTAT values must be returned.

$.02 -Ron Shepard

On Wednesday, July 27, 2022 at 1:34:58 AM UTC+10, Ron Shepard wrote:
> On 7/26/22 5:29 AM, Robin Vowels wrote:
> > On Tuesday, July 26, 2022 at 6:21:31 PM UTC+10, Ron Shepard wrote:
> [...]
> >>> Execution of an input/output statement statement containing
> >>> this specifier causes ios to become defined:
> >>>
> >>> (1) with a zero value if neither an error condition nor
> >>> an end-of-file condition is encountered by the processor.
> >>>
> >>> (2) with a processor-dependent positive integer value if an
> >>> error condition is encountered, or
> > .
> >> This only occurs "if an error condition is encountered". The f77
> >> standard does not specify that reading past an EOF marker is an error
> >> condition. Neither does it specify that it is not an error condition.
> > .
> > The F77 and subsequent standards specify two kinds of things:
> > 1. an end-of-file condition;
> > 2. an error condition.
> > If the event is not an end-of-file condition, it is therefore an error condition.
> > It is clear and unequivocal.
..
> Show in the text where these are the only two choices when an end of
> file is encountered. I don't think it does, I think it leaves it
> unspecified, and I think it did so purposefully in order to allow, but
> not require, reading more than one file from a tape, card deck, etc.
..
I already have. See my earlier post where the three alternatives are
enunciated.

On Tuesday, July 26, 2022 at 12:51:09 PM UTC-4, Robin Vowels wrote:
> On Wednesday, July 27, 2022 at 1:34:58 AM UTC+10, Ron Shepard wrote:
> > On 7/26/22 5:29 AM, Robin Vowels wrote:
> > > On Tuesday, July 26, 2022 at 6:21:31 PM UTC+10, Ron Shepard wrote:
> > [...]
> > >>> Execution of an input/output statement statement containing
> > >>> this specifier causes ios to become defined:
> > >>>
> > >>> (1) with a zero value if neither an error condition nor
> > >>> an end-of-file condition is encountered by the processor.
> > >>>
> > >>> (2) with a processor-dependent positive integer value if an
> > >>> error condition is encountered, or
> > > .
> > >> This only occurs "if an error condition is encountered". The f77
> > >> standard does not specify that reading past an EOF marker is an error
> > >> condition. Neither does it specify that it is not an error condition.
> > > .
> > > The F77 and subsequent standards specify two kinds of things:
> > > 1. an end-of-file condition;
> > > 2. an error condition.
> > > If the event is not an end-of-file condition, it is therefore an error condition.
> > > It is clear and unequivocal.
> .
> > Show in the text where these are the only two choices when an end of
> > file is encountered. I don't think it does, I think it leaves it
> > unspecified, and I think it did so purposefully in order to allow, but
> > not require, reading more than one file from a tape, card deck, etc.
> .
> I already have. See my earlier post where the three alternatives are
> enunciated.

A number of environments support multi-file formats MSWindows uses ctrl-Z (the EOF character). in formatted files as a file separator and lets you continue reading, gfortran does not appear to allow you to read past the ctrl-Z. Note that in cygwin the ctrl-Z is not recognized as an EOF by gfortran; but ifort appears to recoginize it as a file separator on Linux platforms (on all platforms?) as an EOF with the ability to ontinue on. I have found the inconsistency to be an issue, and had to use the ISO_C_Binding interface to use the C routines to get consist behavior when trying to "follow" a file being written to be other processes and for reliably reading from FIFO files (although some compilers did just what I wanted at the time). I never filed bug reports on these as they seemed specifically avoided by the standard , allowing the behavior to be processor dependent. Does anything think it should be forbidden to read a multi-file file as formatted I/o (which appears to be the case with gfortran, which does not seem to allow additional I/O ; but maybe it does if a backspace is used (?)). Or is the desire to be able to read further, either because you are readina a multi-file file (definitely a system=dependent creature) or a file still being updated by another process? Regardless of the error messages what are the capabilities missing that you need? I find not being able to read binary streams or pipes from stdin in a standard format FAR more irritating myself.

On Saturday, July 30, 2022 at 3:19:39 PM UTC-7, John wrote:
> A number of environments support multi-file formats MSWindows uses ctrl-Z (the EOF character).

The ctrl-Z EOF character is from CP/M days, and for some reason is still around.

The CP/M file system only keeps track of how many blocks are in a file.
For text files, there is ctrl-Z at the end, so it knows the exact end.

For not very good reasons, this lasted into MS-DOS, even though it does keep
track of file length in bytes.

In MS-DOS 3.2 days, I used to do bitmap image printing on EPSON and HP
printers, which means printing non-ASCII data. The MS-DOS print spooler
would end on ctrl-Z, so I had to keep those out of the file. A few other
characters it would do funny things with.

>>>>>> If you read (sequentially) past the end-of-file, gfortran sets the value
>>>>>> of IOSTAT to -1, but if you read a second time, gfortran sets the value
>>>>>> of IOSTAT to 5001. I discovered this situation after having written a
>>>>>> program expecting subsequent READs to all return a negative number, and
>>>>>> of course the program didn't behave as expected until I investigated the
>>>>>> problem. So I'm curious as to why the choice was made to have IOSTAT
>>>>>> set to something other than -1 on any READ attempt after the end-of-file
>>>>>> condition has been triggered. Isn't the file pointer still just beyond
>>>>>> the last record in the file, even after the first failed READ?

>>>>> You are expected to test for IOSTAT and deal with the end-of-file condition.
>>>>> You are not expected to continue reading the file.

>>>> I actually do test for IOSTAT and deal with the end-of-file condition by
>>>> exiting the DO loop with the READ statement. But once the DO loop has
>>>> been exited, the program is in an outer DO loop, which can also read the
>>>> file.

>>> You need to fix the logic.

>> Apparently I haven't been clear.
>> The program has already been fixed.

> It had NOT been fixed when you wrote the first paragraph above.

On the contrary, the problem was identified and the code modified to deal
with the processor dependency BEFORE I had even started this thread. Of
course, I've said that before. Why do you insist on repeating the same
false claims?

> You wrote: "But once the DO loop has been exited, the program is in
> an outer DO loop, which can also read the file."

And what I wrote is correct. It's still correct, as one loop reads data
and the other loop reads metadata. Of course, I had already written that
as well.

>>>>> The closest anyone has come is Steve Lionel, who said he could
>>>>> make an argument for the second instance not being -1, but he didn't
>>>>> present that argument. That ifort returns -1 upon a second READ
>>>>> demonstrates that the situation is "processor dependent".

> The situation is NOT "processor dependent". The actual numerical value
> is processor dependent", but the sign of the value is NOT. The sign
> is required to be positive. ifort is not standard-conforming.

The sign is required to be positive for error conditions. From reading
the entire thread, it is quite clearly debatable whether reading past
the end of the file more than once is an end-of-file condition or an
error condition. It's situations like this one that often trigger an
"interpretation" of the standard by the standards committee. Maybe
some future standard will clarify the situation. That you fall on one
side of the debate does not mean there are not others on the other side
of the debate. The way I've interpreted the responses from others is
that the presence of a single physical end-of-file marker such as Ctrl-Z
could allow the file pointer to be positioned after the end of the file,
but BEFORE the end-of-file marker, such that a subsequent READ would
cause the reading of the end-of-file marker and trigger the end-of-file
condition, after which the file pointer would be positioned AFTER the
end-of-file marker, and then yet another READ would trigger an error
condition. But if there is no end-of-file marker, then the file pointer
could not be positioned any farther than the end of the file, such that
it remains in the same place no matter how many attempts are made to
READ beyond it. One such READ would look like any other such READ.

>> You wrote "the" standard as if there has been only one.

> There have been a number of standards published.

Glad you agree. Now, try to prove your claim that I haven't read the
standard.

> All say the same thing about IOSTAT since the keyword
> was introduced in FORTRAN 77 -- in regard to the
> value returned for no errors (zero), end of file (a negative
> value) and an error (a positive value).

You seem to be having trouble identifying what the issue is here. No
one is questioning whether positive is for errors and negative is for
end-of-file conditions. The issue is whether multiple reads past the
end of file are all end-of-file conditions or only the first is an
end-of-file condition.

>> In reality, there
>> have been multiple Fortran standards. I have a hardcopy of one of the
>> earlier standards and have read it. I have reference manuals to multiple
>> more recent compilers and I have read them as well. Since you do not know
>> the standard to which my program was written, and you also don't know which
>> of the standards or reference manuals I have read, you're not in a position
>> to make the claim that you did.

> What you say is irrelevant with regard to IOSTAT.

What I said *is* relevant to your claim that I haven't read the standard.

>>>>> My program *WAS* incompatible with gfortran's
>>>>> handling of a second end-of-file READ.

>>>> No, your program was wrong.

>>> Looks like you've finally admitted (tacitly) that you had your tenses wrong.
>>> Given that the different compilers return IOSTAT values with different signs
>>> for the same second end-of-file READ, it can be argued that the situation is
>>> "processor dependent".

>> All the IOSTAT values are processor-dependent (except for zero).
>> However, the value returned for end-of-file is negative.
>> The value for an error condition is positive.
>> This information is in the standard.

>> Irrelevant,

> It's very relevant, since you were testing for an IOSTAT value
> of the wrong sign.

On the contrary, I was testing for an IOSTAT value that indicates an
end-of-file condition. If you've reached the end of the file in one
read loop, one might expect that you've also reached the end of the
file in a different loop that reads the same file.

>>>> given that my program does not test for specific processor-dependent
>>>> values; rather, it tests for negative values. The outer DO loop's IOSTAT negative
>>>> value test has been superfluous since the program now exits the outer named DO loop
>>>> when the inner DO loop encounters the end-of-file condition.

>>>> Forty years ago, programs that OPENed a file and
>>>> started READing worked just fine with compilers that set the file pointer to
>>>> the beginning of the file, until they were moved to a BSD UNIX system whose
>>>> compiler, by default, OPENed a file with the pointer at the end of the file.
>>>> The program wasn't "wrong"; rather, it was incompatible with a processor
>>>> dependency.

>>> Your program was in error when you tried to read the file again,
>>> after receiving end-of-file notification.

>>> Rather, an error condition was triggered when the program tried to read
>>> the file again,

>>> And because your program contains an error, it is not standard conforming.

>> My program does not contain an error. The version that existed prior to me
>> even starting this thread contained an incompatibility with a gfortran
>> processor-dependent feature.

> Your program contained an error.

My program contained an incompatibility with a gfortran processor-dependent
feature.

> It first tested for a negative
> value indicating end-of-file, and then attempted to read another
> record that caused gfortran to return a positive value, indicating
> an error condition. Your program expected another negative value,

That's because my program expected that once the end of the file was
reached, it was still at the end of the file.

> instead of the positive vaue that was require by the Standard.

On the contrary, the standard requires a positive vaue [sic] for an
error condition. What we're dealing with here is a file pointer that
is past the last record of the file.

>>>>>> The current version is compatible with gfortran.

>>>>> but the code included a test on the value of IOSTAT to
>>>>> deal with the condition.

>>>>> That's why you received a positive number for IOSTAT when you tried
>>>>> to read the file after receiving end-of-file.

>>>> Yet ifort returns a negative number. Are you arguing that ifort is in
>>>> error?

>>> ifort is in error.

>> File a bug report for ifort,

> No, if you don't like it, you file a bug report with ifort.

I don't use ifort. You're the one who is claiming that it is in error,
not me. I have no proof that ifort is in error. As such, I have no
motivation to file a bug report.

On Friday, August 12, 2022 at 9:00:23 PM UTC-7, Dave Tholen wrote:

(snip)

> The sign is required to be positive for error conditions. From reading
> the entire thread, it is quite clearly debatable whether reading past
> the end of the file more than once is an end-of-file condition or an
> error condition. It's situations like this one that often trigger an
> "interpretation" of the standard by the standards committee. Maybe
> some future standard will clarify the situation. That you fall on one
> side of the debate does not mean there are not others on the other side
> of the debate. The way I've interpreted the responses from others is
> that the presence of a single physical end-of-file marker such as Ctrl-Z
> could allow the file pointer to be positioned after the end of the file,
> but BEFORE the end-of-file marker, such that a subsequent READ would
> cause the reading of the end-of-file marker and trigger the end-of-file
> condition, after which the file pointer would be positioned AFTER the
> end-of-file marker, and then yet another READ would trigger an error
> condition. But if there is no end-of-file marker, then the file pointer
> could not be positioned any farther than the end of the file, such that
> it remains in the same place no matter how many attempts are made to
> READ beyond it. One such READ would look like any other such READ.
I guess so.

The description of "end of file record" allows for a physical or virtual
version. It mostly matters for BACKSPACE to work.

Much of the Fortran standard is written to allow for various actual
implementations over the years. And partly that comes from the
record oriented nature of Fortran I/O.

In C, once you get to EOF, you will keep getting one, unless the file
length increases while your program is running.

There are some complications in both Fortran and C when you do
both reading and writing on the same file.

>>>> If I understand it right, you should test for not zero, and act accordingly.

>>>> It is negative for EOF, but positive for I/O errors, which most likely you
>>>> should also exit your loop, and/or handle appropriately.

>>> Not in this particular case. In older versions of the data file I'm
>>> processing, they used csv format to present dozens and dozens of
>>> quantities for each object in the database, and when a value wasn't
>>> available, they simply omitted it, leading to consecutive commas,
>>> and gfortran's list-directed READ statement handled it splendidly.
>>> However, in the latest version of the data file, a missing value is
>>> now represented as "null". For example, five values might be in
>>> this file as:
>>>
>>> 18,97.43,null,-4.31,102
>>>
>>> but attempting to read the characters "null" into an INTEGER or REAL
>>> variable triggers an I/O error.

> Characters are characters, and cannot be read into an integer or real variable.

Hence why I said it triggers an I/O error.

> An appropriate variable would be a CHARACTER variable, but then the
> characters NULL would need to be enclosed in apostrophes.

The data file does have some entries whose values are characters, and
they do enclose those in quotation marks, but not the null entries. I
preferred their previous approach of simply omitting them, leading to
consecutive commas.

> A better approach might be to read the entire line into a CHARACTER variable,
> and then to scan it for 'null, and then to delete the word. Finally read the
> altered line.

I implemented that long ago.

>>>>> If I understand it right, you should test for not zero, and act accordingly.
>>>>> It is negative for EOF, but positive for I/O errors, which most likely you
>>>>> should also exit your loop, and/or handle appropriately.

>>>> Not in this particular case. In older versions of the data file I'm
>>>> processing, they used csv format to present dozens and dozens of
>>>> quantities for each object in the database, and when a value wasn't
>>>> available, they simply omitted it, leading to consecutive commas,
>>>> and gfortran's list-directed READ statement handled it splendidly.
>>>> However, in the latest version of the data file, a missing value is
>>>> now represented as "null". For example, five values might be in
>>>> this file as:
>>>> 18,97.43,null,-4.31,102
>>>> but attempting to read the characters "null" into an INTEGER or REAL
>>>> variable triggers an I/O error.

>> Characters are characters, and cannot be read into an integer or real variable.
>> An appropriate variable would be a CHARACTER variable, but then the
>> characters NULL would need to be enclosed in apostrophes.
>> A better approach might be to read the entire line into a CHARACTER variable,
>> and then to scan it for 'null, and then to delete the word.  Finally read the
>> altered line.

> If each READ statement is definitely reading one and only one line, then reading each line into a character variable, deleting each
> instance of the word 'null', and then reading data from the character variable seems like the easiest solution by far.

And that's what I had implemented months ago. That DO loop exited when the INDEX
function returned a zero value. I'm just glad that modern hardware and compilers
allow for CHARACTER variables at least 2000 characters long.