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?
On a completely separate matter, I have a different program that
didn't behave as expected, and that misbehavior was totally repeatable.
In an attempt to debug the program, I added a WRITE statement to check
on the value of a variable during execution. However, once the WRITE statement was added, the program started behaving properly, repeatably.
Comment out the added WRITE statement, and the program once again
misbehaves, repeatedly. Re-enable the WRITE statement, and everything
is once again hunky-dory. Damned frustrating. It's too easy to blame
the optimizer. Anybody have any generic advice on what to look for in
such a situation?
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?
On a completely separate matter, I have a different program that
didn't behave as expected, and that misbehavior was totally repeatable.
In an attempt to debug the program, I added a WRITE statement to check
on the value of a variable during execution. However, once the WRITE statement was added, the program started behaving properly, repeatably. Comment out the added WRITE statement, and the program once again
misbehaves, repeatedly. Re-enable the WRITE statement, and everything
is once again hunky-dory. Damned frustrating. It's too easy to blame
the optimizer. Anybody have any generic advice on what to look for in
such a situation?
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.
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.
On a completely separate matter, I have a different program that
didn't behave as expected, and that misbehavior was totally repeatable.
In an attempt to debug the program, I added a WRITE statement to check
on the value of a variable during execution. However, once the WRITE
statement was added, the program started behaving properly, repeatably.
That suggests that there is a bug in your program.
Possibly something has
been overwritten.
Turn on subscript bounds checking (if available).
And while you're at it, turn on all checks.
Comment out the added WRITE statement, and the program once again
misbehaves, repeatedly. Re-enable the WRITE statement, and everything
is once again hunky-dory. Damned frustrating. It's too easy to blame
the optimizer. Anybody have any generic advice on what to look for in
such a situation?
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?
What version of the compiler and operating system?
What does IOMSG tell you?
Likely, you have hit two different errors.
On a completely separate matter, I have a different program that
didn't behave as expected, and that misbehavior was totally repeatable.
In an attempt to debug the program, I added a WRITE statement to check
on the value of a variable during execution. However, once the WRITE
statement was added, the program started behaving properly, repeatably.
Comment out the added WRITE statement, and the program once again
misbehaves, repeatedly. Re-enable the WRITE statement, and everything
is once again hunky-dory. Damned frustrating. It's too easy to blame
the optimizer. Anybody have any generic advice on what to look for in
such a situation?
Remove the write statement and compile with -Wall -fcheck=all. This
might find where you are stomping on memory.
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?
On Friday, July 15, 2022 at 4:47:37 AM UTC-7, Dave Tholen wrote:
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 valueIf I understand it right, you should test for not zero, and act accordingly.
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?
It is negative for EOF, but positive for I/O errors, which most likely you should also exit your loop, and/or handle appropriately.
Otherwise, it makes some sense. In the first case, there is actual EOF.
In the second, reading after EOF, is an I/O error, and so reported.
Unless you plan to test for and take appropriate action for different
I/O errors, taking action for any non-zero value makes sense.
I believe this is a not unusual error in some other languages,
which I won't mention.
On Fri, 15 Jul 2022 07:45:56 -0700, Robin Vowels wrote:.
You are expected to test for IOSTAT and deal with the end-of-file condition.MIL-STD-1753 specified that you could, when reading magnetic tape
You are not expected to continue reading the file.
(see
https://stevelionel.com/drfortran/2020/05/16/doctor-fortran-in-military- strength/).
The Fortran standard says (12.11.1), that when an "endfile record is encountered during the reading of a file connected for sequential access", "if the file specified in the input statement is an external record file,
it is positioned after the endfile record;" (12.11.3). What happens after that is not specified, though you are allowed to BACKSPACE over the
endfile record. Note that there doesn't need to be any physical representation of an endfile record.
gfortran is within its rights to give you a different IOSTAT value in this case, and I could make an argument that -1 is NOT the correct thing to
return here. I tried ifort and nagfor - ifort returns -1 on the read past
the EOF, nagfor uses 210, corresponding to "READ/WRITE attempted after ENDFILE on unit 1". (I can't get too worked up over ifort returning -1, however...)
.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.
It also tests IOSTAT to deal with the end-of-file condition,.
but.
it tested for a negative number, which IOSTAT was no longer set to.
And if you must know why the nested DO loops, one loop dealt with data.
while the other loop dealt with metadata. It was easily fixable. My
question here was not about how to fix the problem, but rather to find
out the rationale for changing the value of IOSTAT in such a situation.
My expectation was that IOSTAT would remain negative. My expectation
was wrong, hence the curiosity.
On a completely separate matter, I have a different program that
didn't behave as expected, and that misbehavior was totally repeatable.
In an attempt to debug the program, I added a WRITE statement to check
on the value of a variable during execution. However, once the WRITE
statement was added, the program started behaving properly, repeatably.
That suggests that there is a bug in your program.Brilliant.
Possibly something hasI already thought about that, hence the WRITE statement to examine
been overwritten.
the values of the array indices.
The values were within range and.
the program worked properly with the WRITE statement enabled. Comment
out the WRITE statement, and the misbehavior returned. Hence the
frustration.
Turn on subscript bounds checking (if available).
And while you're at it, turn on all checks.
Easier said than done, as the program was built from dozens of separately written and compiled subprograms. It has not always been obvious to me whether a compilation flag needs to be applied to every single subprogram.
in order to accomplish a goal.
Comment out the added WRITE statement, and the program once again
misbehaves, repeatedly. Re-enable the WRITE statement, and everything
is once again hunky-dory. Damned frustrating. It's too easy to blame
the optimizer. Anybody have any generic advice on what to look for in
such a situation?
On Friday, July 15, 2022 at 4:47:37 AM UTC-7, Dave Tholen wrote:.
If you read (sequentially) past the end-of-file, gfortran sets the valueI haven't thought about this in a lot of years, but in the days of
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?
magnetic tapes, some systems allowed one to read the EOF,
and then go on to the next file on the tape.
Though Fortran 66 has no method for detecting EOF, you are just
supposed to stop reading before it happens.
On Friday, July 15, 2022 at 4:47:37 AM UTC-7, Dave Tholen wrote:.
If you read (sequentially) past the end-of-file, gfortran sets the valueI haven't thought about this in a lot of years, but in the days of
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?
magnetic tapes, some systems allowed one to read the EOF,
and then go on to the next file on the tape.
Though Fortran 66 has no method for detecting EOF, you are just
supposed to stop reading before it happens.
I believe for tapes in Unix, when you get to the end, the system
call return 0 bytes, as the sign of the EOF, and then you go onto
the next file. (That is, past the tape mark.)
Disk files don't do that, though.
Dave Tholen wrote:<snip>
On a completely separate matter, I have a different program thatRemove the write statement and compile with -Wall -fcheck=all. This
didn't behave as expected, and that misbehavior was totally repeatable.
In an attempt to debug the program, I added a WRITE statement to check
on the value of a variable during execution. However, once the WRITE
statement was added, the program started behaving properly, repeatably.
Comment out the added WRITE statement, and the program once again
misbehaves, repeatedly. Re-enable the WRITE statement, and everything
is once again hunky-dory. Damned frustrating. It's too easy to blame
the optimizer. Anybody have any generic advice on what to look for in
such a situation?
might find where you are stomping on memory.
You are expected to test for IOSTAT and deal with the end-of-file
condition.
You are not expected to continue reading the file.
MIL-STD-1753 specified that you could, when reading magnetic tape (see https://stevelionel.com/drfortran/2020/05/16/doctor-fortran-in-military- strength/).
The Fortran standard says (12.11.1), that when an "endfile record is encountered during the reading of a file connected for sequential access", "if the file specified in the input statement is an external record file,
it is positioned after the endfile record;" (12.11.3). What happens after that is not specified, though you are allowed to BACKSPACE over the
endfile record. Note that there doesn't need to be any physical representation of an endfile record.
gfortran is within its rights to give you a different IOSTAT value in this case, and I could make an argument that -1 is NOT the correct thing to
return here.
I tried ifort and nagfor - ifort returns -1 on the read past
the EOF, nagfor uses 210, corresponding to "READ/WRITE attempted after ENDFILE on unit 1". (I can't get too worked up over ifort returning -1, however...)
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.
It also tests IOSTAT to deal with the end-of-file condition,
The program has already hit the end of file.
Now you are trying to read read the same file at the same place.
but
it tested for a negative number, which IOSTAT was no longer set to.
You need to avoid reading after end of file has been detected.
And if you must know why the nested DO loops, one loop dealt with data
while the other loop dealt with metadata. It was easily fixable. My
question here was not about how to fix the problem, but rather to find
out the rationale for changing the value of IOSTAT in such a situation.
My expectation was that IOSTAT would remain negative. My expectation
was wrong, hence the curiosity.
On a completely separate matter, I have a different program that
didn't behave as expected, and that misbehavior was totally repeatable. >>>> In an attempt to debug the program, I added a WRITE statement to check >>>> on the value of a variable during execution. However, once the WRITE
statement was added, the program started behaving properly, repeatably.
That suggests that there is a bug in your program.
Brilliant.
Possibly something has
been overwritten.
I already thought about that, hence the WRITE statement to examine
the values of the array indices.
In every program unit, subroutine and function in the entire program?
.The values were within range and
the program worked properly with the WRITE statement enabled. Comment
out the WRITE statement, and the misbehavior returned. Hence the
frustration.
Turn on subscript bounds checking (if available).
And while you're at it, turn on all checks.
Easier said than done, as the program was built from dozens of separately
written and compiled subprograms. It has not always been obvious to me
whether a compilation flag needs to be applied to every single subprogram
in order to accomplish a goal.
Obviously, program checking needs to be specified for every separate compilation,
as the apparent overwriting could be in any one or more subroutine and function.
Comment out the added WRITE statement, and the program once again
misbehaves, repeatedly. Re-enable the WRITE statement, and everything
is once again hunky-dory. Damned frustrating. It's too easy to blame
the optimizer. Anybody have any generic advice on what to look for in
such a situation?
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?
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.
Otherwise, it makes some sense. In the first case, there is actual EOF.
In the second, reading after EOF, is an I/O error, and so reported.
Unless you plan to test for and take appropriate action for different
I/O errors, taking action for any non-zero value makes sense.
I believe this is a not unusual error in some other languages,
which I won't mention.
On Fri, 15 Jul 2022 15:46:36 -1000, Dave Tholen wrote:
I'm unfamiliar with IOMSG. Sounds like an intrinsic that returns a text description of an IOSTAT numerical value, but I don't see it listedIt's not an intrinsic, it's another keyword for the I/O statement, like IOSTAT. It was new in Fortran 2018.
among the intrinsic procedures for gfortran. Could you elaborate?
I'm unfamiliar with IOMSG. Sounds like an intrinsic that returns a text description of an IOSTAT numerical value, but I don't see it listed
among the intrinsic procedures for gfortran. Could you elaborate?
On Friday, July 15, 2022 at 4:47:37 AM UTC-7, Dave Tholen wrote:
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?
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.
Otherwise, it makes some sense. In the first case, there is actual EOF.
In the second, reading after EOF, is an I/O error, and so reported.
Unless you plan to test for and take appropriate action for different
I/O errors, taking action for any non-zero value makes sense.
I believe this is a not unusual error in some other languages,
which I won't mention.
On Saturday, July 16, 2022 at 4:41:04 AM UTC-7, Dave Tholen wrote:.
(snip, I wrote)
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.
I do NOT want to exit the READ loop.
However, once the end-of-file is reached, I do want to exit the READOn either EOF or I/O error, there is no guarantee as to what
loop.
is actually stored, or where the file is positioned.
Otherwise, it makes some sense. In the first case, there is actual EOF. In the second, reading after EOF, is an I/O error, and so reported.
So, prior to the READ that triggers the end-of-file condition, theThe standard does have some discussion on that imaginary
file pointer is after the last record of the file, but before the EOF,
and after the READ that triggers the end-of-file condition, the file pointer is now after some imaginary EOF? There is no physical EOF associated with the file. Does the compiler give the file a logical
EOF marker and is able to position the file pointer before and after it?
EOF record, while indicating that it might not be an actual
physical anything. I am not sure if some historical system
had a physical EOF record that the standard emulates.
In any case, EOF is not an error, and so actual error is different.
Unless you plan to test for and take appropriate action for different
I/O errors, taking action for any non-zero value makes sense.
.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.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
You are not expected to continue reading the file.
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 was fixed before I even posted on this forum. The question is not.
how to fix the problem. The question is why the value of IOSTAT was
changed.
There must be some rationale..
That's just it: same file, same place, same action, yet a differentIt also tests IOSTAT to deal with the end-of-file condition,The program has already hit the end of file.
Now you are trying to read read the same file at the same place.
IOSTAT result. Not what I had expected.
.Why? IOSTAT was added so that a program could handle error conditions.butYou need to avoid reading after end of file has been detected.
it tested for a negative number, which IOSTAT was no longer set to.
My program was designed to deal with the error condition. Had gfortran consistently returned a negative IOSTAT for every attempt to READ past
the end-of-file, my program would have worked exactly as intended.
Had I used ifort, my program would have worked exactly as intended..
And if you must know why the nested DO loops, one loop dealt with data
while the other loop dealt with metadata. It was easily fixable. My
question here was not about how to fix the problem, but rather to find
out the rationale for changing the value of IOSTAT in such a situation.
My expectation was that IOSTAT would remain negative. My expectation
was wrong, hence the curiosity.
On a completely separate matter, I have a different program that
didn't behave as expected, and that misbehavior was totally repeatable. >>>> In an attempt to debug the program, I added a WRITE statement to check >>>> on the value of a variable during execution. However, once the WRITE >>>> statement was added, the program started behaving properly, repeatably.
That suggests that there is a bug in your program.
Brilliant.
Possibly something has
been overwritten.
I usually sprinkle WRITE statements around to isolate where the crashI already thought about that, hence the WRITE statement to examineIn every program unit, subroutine and function in the entire program?
the values of the array indices.
is happening. As I narrow things down, unnecessary WRITE statements are either removed or commented out. In this particular case, I got it down
to a single WRITE statement that could trigger proper behavior.
The values were within range and
the program worked properly with the WRITE statement enabled. Comment
out the WRITE statement, and the misbehavior returned. Hence the
frustration.
.Turn on subscript bounds checking (if available).
And while you're at it, turn on all checks.
So, you're saying that if my program has subprograms A, B, C, D, and E,Easier said than done, as the program was built from dozens of separately >> written and compiled subprograms. It has not always been obvious to meObviously, program checking needs to be specified for every separate compilation,
whether a compilation flag needs to be applied to every single subprogram >> in order to accomplish a goal.
as the apparent overwriting could be in any one or more subroutine and function.
and the crash occurs while it's executing subprogram C, the apparent overwriting could be in A, B, D, or E?
Comment out the added WRITE statement, and the program once again
misbehaves, repeatedly. Re-enable the WRITE statement, and everything >>>> is once again hunky-dory. Damned frustrating. It's too easy to blame >>>> the optimizer. Anybody have any generic advice on what to look for in >>>> such a situation?
.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?
Apparently I haven't been clear. The program has already been fixed.You need to fix the logic.You are expected to test for IOSTAT and deal with the end-of-file condition.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
You are not expected to continue reading the file.
been exited, the program is in an outer DO loop, which can also read the >> file.
It was fixed before I even posted on this forum. The question is not
how to fix the problem. The question is why the value of IOSTAT was
changed. There must be some rationale.
That's just it: same file, same place, same action, yet a differentIt also tests IOSTAT to deal with the end-of-file condition,The program has already hit the end of file.
Now you are trying to read read the same file at the same place.
IOSTAT result. Not what I had expected.
Why? IOSTAT was added so that a program could handle error conditions.butYou need to avoid reading after end of file has been detected.
it tested for a negative number, which IOSTAT was no longer set to.
My program was designed to deal with the error condition. Had gfortran consistently returned a negative IOSTAT for every attempt to READ past
the end-of-file, my program would have worked exactly as intended. Had
I used ifort, my program would have worked exactly as intended.
And if you must know why the nested DO loops, one loop dealt with data
while the other loop dealt with metadata. It was easily fixable. My
question here was not about how to fix the problem, but rather to find
out the rationale for changing the value of IOSTAT in such a situation.
My expectation was that IOSTAT would remain negative. My expectation
was wrong, hence the curiosity.
On a completely separate matter, I have a different program that
didn't behave as expected, and that misbehavior was totally repeatable. >>>> In an attempt to debug the program, I added a WRITE statement to check >>>> on the value of a variable during execution. However, once the WRITE >>>> statement was added, the program started behaving properly, repeatably.
That suggests that there is a bug in your program.
Brilliant.
Possibly something has
been overwritten.
I usually sprinkle WRITE statements around to isolate where the crashI already thought about that, hence the WRITE statement to examineIn every program unit, subroutine and function in the entire program?
the values of the array indices.
is happening. As I narrow things down, unnecessary WRITE statements are either removed or commented out. In this particular case, I got it down
to a single WRITE statement that could trigger proper behavior.
The values were within range and
the program worked properly with the WRITE statement enabled. Comment
out the WRITE statement, and the misbehavior returned. Hence the
frustration.
.Turn on subscript bounds checking (if available).
And while you're at it, turn on all checks.
Easier said than done, as the program was built from dozens of separately >> written and compiled subprograms. It has not always been obvious to meObviously, program checking needs to be specified for every separate compilation,
whether a compilation flag needs to be applied to every single subprogram >> in order to accomplish a goal.
as the apparent overwriting could be in any one or more subroutine and function.
So, you're saying that if my program has subprograms A, B, C, D, and E,.
and the crash occurs while it's executing subprogram C, the apparent overwriting could be in A, B, D, or E?
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. I do NOT want to exit the READ loop.
However, once the end-of-file is reached, I do want to exit the READ
loop.
Otherwise, it makes some sense. In the first case, there is actual EOF.
In the second, reading after EOF, is an I/O error, and so reported.
So, prior to the READ that triggers the end-of-file condition, the
file pointer is after the last record of the file, but before the EOF,
and after the READ that triggers the end-of-file condition, the file
pointer is now after some imaginary EOF? There is no physical EOF
associated with the file. Does the compiler give the file a logical
EOF marker and is able to position the file pointer before and after it?
Unless you plan to test for and take appropriate action for different
I/O errors, taking action for any non-zero value makes sense.
I've written numerous programs where different actions are taken for different I/O errors. A hypothetical (and trivial) example: A
program that converts Fahrenheit to Celsius. DO loop with WRITE
statement that prompts the user to enter a temperature in Fahrenheit
and a READ statement that accepts the user's input. Type in "abc"
and rather than crashing or exiting the loop, the program can say
"try again" and wait for another entry. But enter a CTRL-Z (an
EOF on Windows), and the loop can exit gracefully.
On Sunday, July 17, 2022 at 3:40:55 AM UTC+10, gah4 wrote:
On Saturday, July 16, 2022 at 4:41:04 AM UTC-7, Dave Tholen wrote:.
(snip, I wrote)
If I understand it right, you should test for not zero, and act accordingly.Not in this particular case. In older versions of the data file I'm
It is negative for EOF, but positive for I/O errors, which most likely you >>>> should also exit your loop, and/or handle appropriately.
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.
Characters are characters, and cannot be read into an integer or real variable.
On a completely separate matter, I have a different program that
didn't behave as expected, and that misbehavior was totally repeatable.
In an attempt to debug the program, I added a WRITE statement to check
on the value of a variable during execution. However, once the WRITE
statement was added, the program started behaving properly, repeatably.
Comment out the added WRITE statement, and the program once again
misbehaves, repeatedly. Re-enable the WRITE statement, and everything
is once again hunky-dory. Damned frustrating. It's too easy to blame >>> the optimizer. Anybody have any generic advice on what to look for in
such a situation?
Remove the write statement and compile with -Wall -fcheck=all. This
might find where you are stomping on memory.
I would add -Werror. If you always compile without warnings, your life will be simpler.
If the presumably unlikely event that you're not already using IMPLICIT NONE in every program unit, I would do that, too.
Among the other things mentioned, a WRITE statement might mask problems caused by a variable that's not assigned a value before it's
used.
If all else fails, the debugger is your friend. If you haven't experienced the thrill of stepping through assembler instructions
finding where your wayward variable is stored and examining its value and figuring out how it got to be what it is, this could be
your chance.
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.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
You are not expected to continue reading the file.
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.
But it hasn't been fixed.
You admitted it.
You said that after detecting end of file using IOSTAT, you exited the loop, and the outer loop then proceeded to execute READs on the same file.
It was fixed before I even posted on this forum. The question is not
how to fix the problem. The question is why the value of IOSTAT was
changed.
That has already been explained to you.
There must be some rationale.
It also tests IOSTAT to deal with the end-of-file condition,
The program has already hit the end of file.
Now you are trying to read read the same file at the same place.
That's just it: same file, same place, same action, yet a different
IOSTAT result. Not what I had expected.
Again, that has been explained to you.
but
it tested for a negative number, which IOSTAT was no longer set to.
You need to avoid reading after end of file has been detected.
Why? IOSTAT was added so that a program could handle error conditions.
Provided that you deal with the condition and do not do silly things like reading
the same file again, after detecting end-of file.
My program was designed to deal with the error condition. Had gfortran
consistently returned a negative IOSTAT for every attempt to READ past
the end-of-file, my program would have worked exactly as intended.
Listen up. Your program is in error. Fix it.
Had I used ifort, my program would have worked exactly as intended.
And if you must know why the nested DO loops, one loop dealt with data >>>> while the other loop dealt with metadata. It was easily fixable. My
question here was not about how to fix the problem, but rather to find >>>> out the rationale for changing the value of IOSTAT in such a situation. >>>> My expectation was that IOSTAT would remain negative. My expectation
was wrong, hence the curiosity.
On a completely separate matter, I have a different program that
didn't behave as expected, and that misbehavior was totally repeatable. >>>>>> In an attempt to debug the program, I added a WRITE statement to check >>>>>> on the value of a variable during execution. However, once the WRITE >>>>>> statement was added, the program started behaving properly, repeatably.
That suggests that there is a bug in your program.
Brilliant.
Possibly something has
been overwritten.
I already thought about that, hence the WRITE statement to examine
the values of the array indices.
In every program unit, subroutine and function in the entire program?
I usually sprinkle WRITE statements around to isolate where the crash
is happening. As I narrow things down, unnecessary WRITE statements are
either removed or commented out. In this particular case, I got it down
to a single WRITE statement that could trigger proper behavior.
You program has errors.
Find them with the help of debug options
such as subscript bound errors, substring errors, and the like.
The values were within range and
the program worked properly with the WRITE statement enabled. Comment
out the WRITE statement, and the misbehavior returned. Hence the
frustration.
Turn on subscript bounds checking (if available).
And while you're at it, turn on all checks.
Easier said than done, as the program was built from dozens of separately >>>> written and compiled subprograms. It has not always been obvious to me >>>> whether a compilation flag needs to be applied to every single subprogram >>>> in order to accomplish a goal.
Obviously, program checking needs to be specified for every separate compilation,
as the apparent overwriting could be in any one or more subroutine and function.
So, you're saying that if my program has subprograms A, B, C, D, and E,
and the crash occurs while it's executing subprogram C, the apparent
overwriting could be in A, B, D, or E?
Comment out the added WRITE statement, and the program once again
misbehaves, repeatedly. Re-enable the WRITE statement, and everything >>>>>> is once again hunky-dory. Damned frustrating. It's too easy to blame >>>>>> the optimizer. Anybody have any generic advice on what to look for in >>>>>> such a situation?
So, you're saying that if my program has subprograms A, B, C, D, and E,
and the crash occurs while it's executing subprogram C, the apparent
overwriting could be in A, B, D, or E?
The error could be in any of A, B, C, D, E, and/or the main program.
..
Can you provide an example?
..
I haven't used a real GUI debugger since the days of WATCOM on OS/2. If
only gfortran had something like that on Windows.
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?
On a completely separate matter, I have a different program that
didn't behave as expected, and that misbehavior was totally repeatable.
In an attempt to debug the program, I added a WRITE statement to check
on the value of a variable during execution. However, once the WRITE statement was added, the program started behaving properly, repeatably. Comment out the added WRITE statement, and the program once again misbehaves, repeatedly. Re-enable the WRITE statement, and everything
is once again hunky-dory. Damned frustrating. It's too easy to blame
the optimizer. Anybody have any generic advice on what to look for in
such a situation?
.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?
Incorrect; reread my previous statement.But it hasn't been fixed.Apparently I haven't been clear.You need to fix the logic.You are expected to test for IOSTAT and deal with the end-of-file condition.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 are not expected to continue reading the file.
The program has already been fixed.
You admitted it.
Incorrect.
You said that after detecting end of file using IOSTAT, you exited the loop,That was before the fix. Now it is using a named DO loop, and when
and the outer loop then proceeded to execute READs on the same file.
the data-reading DO loop encounters the end-of-file condition, it
exits the outer DO loop, so the outer DO loop's READ statement is
not encountered. That made the value of IOSTAT in the outer DO loop irrelevant. However, that I succeeded in making my program work
properly did not change my curiosity as to why the value of IOSTAT
changed upon the second end-of-file READ.
Where? The closest anyone has come is Steve Lionel, who said he couldIt was fixed before I even posted on this forum. The question is notThat has already been explained to you.
how to fix the problem. The question is why the value of IOSTAT was
changed.
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".
There must be some rationale.
It also tests IOSTAT to deal with the end-of-file condition,
The program has already hit the end of file.
Now you are trying to read read the same file at the same place.
Again, where?That's just it: same file, same place, same action, yet a differentAgain, that has been explained to you.
IOSTAT result. Not what I had expected.
but
it tested for a negative number, which IOSTAT was no longer set to.
You need to avoid reading after end of file has been detected.
Why? IOSTAT was added so that a program could handle error conditions.
.Provided that you deal with the condition and do not do silly things like reading
the same file again, after detecting end-of file.
Hardly silly, given that reading the same file again just triggers yet another
error condition,
and IOSTAT was designed to allow programs to deal with the.
error condition.
My program was designed to deal with the error condition. Had gfortran
consistently returned a negative IOSTAT for every attempt to READ past
the end-of-file, my program would have worked exactly as intended.
Listen up. Your program is in error. Fix it.Listen up: you are incorrect.
My program *WAS* incompatible with gfortran's.
handling of a second end-of-file READ.
However, my program *WAS* compatible.
with ifort's handling of a second end-of-file READ. My program *IS* no longer incompatible with either compiler, and that was the case before I even
posted on this forum. Get your tenses straight.
Had I used ifort, my program would have worked exactly as intended.
And if you must know why the nested DO loops, one loop dealt with data >>>> while the other loop dealt with metadata. It was easily fixable. My
question here was not about how to fix the problem, but rather to find >>>> out the rationale for changing the value of IOSTAT in such a situation. >>>> My expectation was that IOSTAT would remain negative. My expectation >>>> was wrong, hence the curiosity.
On a completely separate matter, I have a different program that >>>>>> didn't behave as expected, and that misbehavior was totally repeatable.
In an attempt to debug the program, I added a WRITE statement to check >>>>>> on the value of a variable during execution. However, once the WRITE >>>>>> statement was added, the program started behaving properly, repeatably.
That suggests that there is a bug in your program.
Brilliant.
Possibly something has
been overwritten.
I already thought about that, hence the WRITE statement to examine
the values of the array indices.
In every program unit, subroutine and function in the entire program?
I usually sprinkle WRITE statements around to isolate where the crash
is happening. As I narrow things down, unnecessary WRITE statements are
either removed or commented out. In this particular case, I got it down
to a single WRITE statement that could trigger proper behavior.
.Your program has errors.
Perhaps. I doubt anyone can guarantee that the optimizer has zero bugs.
It wouldn't be the first time I've encountered a bug in an optimizer..
Clearly there is a bug somewhere, but you can't guarantee that it is in
my code.
.Find them with the help of debug optionsThe WRITE statements showed that my subscripts are within bounds.
such as subscript bound errors, substring errors, and the like.
Substrings are not involved.
The values were within range and
the program worked properly with the WRITE statement enabled. Comment >>>> out the WRITE statement, and the misbehavior returned. Hence the
frustration.
Turn on subscript bounds checking (if available).Easier said than done, as the program was built from dozens of separately
And while you're at it, turn on all checks.
written and compiled subprograms. It has not always been obvious to me >>>> whether a compilation flag needs to be applied to every single subprogram
in order to accomplish a goal.
Obviously, program checking needs to be specified for every separate compilation,
as the apparent overwriting could be in any one or more subroutine and function.
So, you're saying that if my program has subprograms A, B, C, D, and E,
and the crash occurs while it's executing subprogram C, the apparent
overwriting could be in A, B, D, or E?
..
So for your question, it is because EOF is not treated as an error
condition. It is intended to be a normal situation that a programmer can encounter, detect, and continue processing accordingly in a portable
way. However, reading or writing past the EOF might or might not be
allowed on a given device, or for a file on some device. If it is not allowed, then it is an error condition, an exceptional situation that
should not be normally encountered. ..
Can you provide an example?
If your interest is in gaining some insight and answers as opposed to an open-ended discussion, you may also want to post at the Fortran Discourse site:
https://fortran-lang.discourse.group/
And consider posting there first *your own small example* that illustrates what you are doing in your code.
.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.
But it hasn't been fixed.
Incorrect; reread my previous statement.
You admitted it.
Incorrect.
You said that after detecting end of file using IOSTAT, you exited the loop,
and the outer loop then proceeded to execute READs on the same file.
That was before the fix. Now it is using a named DO loop, and when
the data-reading DO loop encounters the end-of-file condition, it
exits the outer DO loop, so the outer DO loop's READ statement is
not encountered. That made the value of IOSTAT in the outer DO loop
irrelevant. However, that I succeeded in making my program work
properly did not change my curiosity as to why the value of IOSTAT
changed upon the second end-of-file READ.
It was fixed before I even posted on this forum. The question is not
how to fix the problem. The question is why the value of IOSTAT was
changed.
That has already been explained to you.
Where? 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".
There must be some rationale.
It also tests IOSTAT to deal with the end-of-file condition,
The program has already hit the end of file.
Now you are trying to read read the same file at the same place.
That's just it: same file, same place, same action, yet a different
IOSTAT result. Not what I had expected.
Again, that has been explained to you.
Again, where?
but
it tested for a negative number, which IOSTAT was no longer set to.
You need to avoid reading after end of file has been detected.
Why? IOSTAT was added so that a program could handle error conditions.
IOSTAT was added so that end-of-file could be detected and dealt with.
IOSTAT was also added so that error conditions could be detected.
[Note that end-of-file is not considered to be an error condition.]
Provided that you deal with the condition and do not do silly things like reading
the same file again, after detecting end-of file.
Hardly silly, given that reading the same file again just triggers yet another
error condition,
No it doesn't. Reading the same file again after end of file has been detected
is the first error condition raised.
IOSTAT returns a negative value for end of file.
IOSTAT returns a positive integer for an error condition.
and IOSTAT was designed to allow programs to deal with the
error condition.
My program was designed to deal with the error condition. Had gfortran >>>> consistently returned a negative IOSTAT for every attempt to READ past >>>> the end-of-file, my program would have worked exactly as intended.
Listen up. Your program is in error. Fix it.
Listen up: you are incorrect.
I am not incorrect. Read the standard.
My program *WAS* incompatible with gfortran's
handling of a second end-of-file READ.
No, your program was wrong.
Your program was in error when you tried to read the file again,
after receiving end-of-file notification.
That's why you received a positive number for IOSTAT when you tried
to read the file after receiving end-of-file.
However, my program *WAS* compatible
with ifort's handling of a second end-of-file READ. My program *IS* no longer
incompatible with either compiler, and that was the case before I even
posted on this forum. Get your tenses straight.
Had I used ifort, my program would have worked exactly as intended.
And if you must know why the nested DO loops, one loop dealt with data >>>>>> while the other loop dealt with metadata. It was easily fixable. My >>>>>> question here was not about how to fix the problem, but rather to find >>>>>> out the rationale for changing the value of IOSTAT in such a situation. >>>>>> My expectation was that IOSTAT would remain negative. My expectation >>>>>> was wrong, hence the curiosity.
On a completely separate matter, I have a different program that >>>>>>>> didn't behave as expected, and that misbehavior was totally repeatable.
In an attempt to debug the program, I added a WRITE statement to check >>>>>>>> on the value of a variable during execution. However, once the WRITE >>>>>>>> statement was added, the program started behaving properly, repeatably.
That suggests that there is a bug in your program.
Brilliant.
Possibly something has
been overwritten.
I already thought about that, hence the WRITE statement to examine >>>>>> the values of the array indices.
In every program unit, subroutine and function in the entire program?
I usually sprinkle WRITE statements around to isolate where the crash
is happening. As I narrow things down, unnecessary WRITE statements are >>>> either removed or commented out. In this particular case, I got it down >>>> to a single WRITE statement that could trigger proper behavior.
Your program has errors.
Perhaps. I doubt anyone can guarantee that the optimizer has zero bugs.
It's common for people to blame the compiler when their program does not work,
especially when they do not bother to read the manual.
It wouldn't be the first time I've encountered a bug in an optimizer.
Clearly there is a bug somewhere, but you can't guarantee that it is in
my code.
Can you guarantee that the bug(s) is not in your code?
Find them with the help of debug options
such as subscript bound errors, substring errors, and the like.
The WRITE statements showed that my subscripts are within bounds.
That's not the same as enabling subscript checks and all other checks.
Substrings are not involved.
The values were within range and
the program worked properly with the WRITE statement enabled. Comment >>>>>> out the WRITE statement, and the misbehavior returned. Hence the
frustration.
Turn on subscript bounds checking (if available).Easier said than done, as the program was built from dozens of separately
And while you're at it, turn on all checks.
written and compiled subprograms. It has not always been obvious to me >>>>>> whether a compilation flag needs to be applied to every single subprogram
in order to accomplish a goal.
Obviously, program checking needs to be specified for every separate compilation,
as the apparent overwriting could be in any one or more subroutine and function.
So, you're saying that if my program has subprograms A, B, C, D, and E, >>>> and the crash occurs while it's executing subprogram C, the apparent
overwriting could be in A, B, D, or E?
On a completely separate matter, I have a different program that
didn't behave as expected, and that misbehavior was totally
repeatable.
In an attempt to debug the program, I added a WRITE statement to check >>>> on the value of a variable during execution. However, once the WRITE >>>> statement was added, the program started behaving properly,
repeatably.
Comment out the added WRITE statement, and the program once again
misbehaves, repeatedly. Re-enable the WRITE statement, and everything >>>> is once again hunky-dory. Damned frustrating. It's too easy to blame >>>> the optimizer. Anybody have any generic advice on what to look for in >>>> such a situation?
Remove the write statement and compile with -Wall -fcheck=all. This
might find where you are stomping on memory.
I would add -Werror. If you always compile without warnings, your
life will be simpler.
Oh, that's a deadly option for me. I use A LOT of implicit type
conversion,
such as doing a calculation internally using double precision, but saving
the result in single precision, such as
snglz = dblex * dbley
-Werror is happy if an explicit REAL() is used. For the single precision version of the real component of a double complex number, one needs to
use
REAL(REAL(dblecmplx)) to make -Werror happy.
If the presumably unlikely event that you're not already using
IMPLICIT NONE in every program unit, I would do that, too.
I'm pretty religious about using IMPLICIT NONE in production code.
Among the other things mentioned, a WRITE statement might mask
problems caused by a variable that's not assigned a value before it's
used.
Intriguing. How would that work? I've been trying to visualize how the addition of a WRITE statement could change the computation.
If all else fails, the debugger is your friend. If you haven't
experienced the thrill of stepping through assembler instructions
finding where your wayward variable is stored and examining its value
and figuring out how it got to be what it is, this could be your chance.
I haven't used a real GUI debugger since the days of WATCOM on OS/2. If only gfortran had something like that on Windows.
"If an end-of-file condition occurs during execution of an input/output statement that contains either an END= specifier or an IOSTAT= specifier, and an error condition does not occur then:
(1) processing of the input list, if any, terminates;
(2) if the statement is a data transfer statement or the end-of-file condition occurs during a wait operation,
all do-variables in the statement that initiated the transfer become undefined;
(3) if the statement is an input statement or the end-of-file condition occurs during a wait operation
for a transfer initiated by an input statement, all effective items resulting from the expansion of list
items or the namelist group in the statement that initiated the transfer become undefined;
(4) if the file specified in the input statement is an external record file, it is positioned after the endfile record;"
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.
But it hasn't been fixed.
Incorrect; reread my previous statement.
You admitted it.
Incorrect.
You said that after detecting end of file using IOSTAT, you exited the loop,
and the outer loop then proceeded to execute READs on the same file.
That was before the fix. Now it is using a named DO loop, and when
the data-reading DO loop encounters the end-of-file condition, it
exits the outer DO loop, so the outer DO loop's READ statement is
not encountered. That made the value of IOSTAT in the outer DO loop
irrelevant. However, that I succeeded in making my program work
properly did not change my curiosity as to why the value of IOSTAT
changed upon the second end-of-file READ.
It was fixed before I even posted on this forum. The question is not >>>> how to fix the problem. The question is why the value of IOSTAT was
changed.
That has already been explained to you.
Where? 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".
There must be some rationale.
It also tests IOSTAT to deal with the end-of-file condition,
The program has already hit the end of file.
Now you are trying to read read the same file at the same place.
That's just it: same file, same place, same action, yet a different
IOSTAT result. Not what I had expected.
Again, that has been explained to you.
Again, where?
but
it tested for a negative number, which IOSTAT was no longer set to.
You need to avoid reading after end of file has been detected.
.Why? IOSTAT was added so that a program could handle error conditions.
IOSTAT was added so that end-of-file could be detected and dealt with. IOSTAT was also added so that error conditions could be detected.But another READ past the end-of-file apparently is considered to be an
[Note that end-of-file is not considered to be an error condition.]
error condition by gfortran, whereas ifort apparently considers it to be
an end-of-file condition.
Provided that you deal with the condition and do not do silly things like reading
the same file again, after detecting end-of file.
You don't know that. In fact, if you read elsewhere in this thread, you'd know that the data file uses the characters "null" in place of a missing numerical value, which triggers multiple error conditions long before a second end-of-file READ occurs. It's hardly the first error conditionHardly silly, given that reading the same file again just triggers yet anotherNo it doesn't. Reading the same file again after end of file has been detected
error condition,
is the first error condition raised.
raised.
IOSTAT returns a negative value for end of file.Yet ifort returns -1 for a second end-of-file READ while gfortran returns 5001. Are you arguing that one of the two compilers is not standard compliant?
IOSTAT returns a positive integer for an error condition.
and IOSTAT was designed to allow programs to deal with the
error condition.
My program was designed to deal with the error condition. Had gfortran >>>> consistently returned a negative IOSTAT for every attempt to READ past >>>> the end-of-file, my program would have worked exactly as intended.
Listen up. Your program is in error. Fix it.
You are incorrect. My program is standard-conforming and works properly.Listen up: you are incorrect.I am not incorrect. Read the standard.
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".My program *WAS* incompatible with gfortran'sNo, your program was wrong.
handling of a second end-of-file READ.
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,Rather, an error condition was triggered when the program tried to read
after receiving end-of-file notification.
the file again,
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?
However, my program *WAS* compatible
with ifort's handling of a second end-of-file READ. My program *IS* no longer
incompatible with either compiler, and that was the case before I even
posted on this forum. Get your tenses straight.
Had I used ifort, my program would have worked exactly as intended.
And if you must know why the nested DO loops, one loop dealt with data >>>>>> while the other loop dealt with metadata. It was easily fixable. My >>>>>> question here was not about how to fix the problem, but rather to find >>>>>> out the rationale for changing the value of IOSTAT in such a situation.
My expectation was that IOSTAT would remain negative. My expectation >>>>>> was wrong, hence the curiosity.
On a completely separate matter, I have a different program that >>>>>>>> didn't behave as expected, and that misbehavior was totally repeatable.
In an attempt to debug the program, I added a WRITE statement to check
on the value of a variable during execution. However, once the WRITE >>>>>>>> statement was added, the program started behaving properly, repeatably.
That suggests that there is a bug in your program.
Brilliant.
Possibly something has
been overwritten.
I already thought about that, hence the WRITE statement to examine >>>>>> the values of the array indices.
In every program unit, subroutine and function in the entire program?
I usually sprinkle WRITE statements around to isolate where the crash >>>> is happening. As I narrow things down, unnecessary WRITE statements are >>>> either removed or commented out. In this particular case, I got it down >>>> to a single WRITE statement that could trigger proper behavior.Your program has errors.
Perhaps. I doubt anyone can guarantee that the optimizer has zero bugs.
It's common for people to blame the compiler when their program does not work,
especially when they do not bother to read the manual.
Hence why I wrote "It's too easy to blame the optimizer."
It wouldn't be the first time I've encountered a bug in an optimizer.
Clearly there is a bug somewhere, but you can't guarantee that it is in
my code.
Can you guarantee that the bug(s) is not in your code?
Obviously not, hence my request for "generic advice on what to look for in such a situation."
Why continue to ask questions for which answers have already been provided?
Find them with the help of debug options
such as subscript bound errors, substring errors, and the like.
The WRITE statements showed that my subscripts are within bounds.
That's not the same as enabling subscript checks and all other checks.
It is the same as checking for subscript bound errors.
Substrings are not involved.
The values were within range and
the program worked properly with the WRITE statement enabled. Comment >>>>>> out the WRITE statement, and the misbehavior returned. Hence the >>>>>> frustration.
Turn on subscript bounds checking (if available).Easier said than done, as the program was built from dozens of separately
And while you're at it, turn on all checks.
written and compiled subprograms. It has not always been obvious to me >>>>>> whether a compilation flag needs to be applied to every single subprogram
in order to accomplish a goal.
Obviously, program checking needs to be specified for every separate compilation,
as the apparent overwriting could be in any one or more subroutine and function.
So, you're saying that if my program has subprograms A, B, C, D, and E, >>>> and the crash occurs while it's executing subprogram C, the apparent >>>> overwriting could be in A, B, D, or E?
..
Are you suggesting that fortran-lang.discourse.group is for insight and that comp.lang.fortran is for open-ended discussions?
And consider posting there first *your own small example* that illustrates what you are doing in your code.You're assuming that the problem can be reproduced with a "small example". The program isn't small. If the simple addition of a WRITE statement can trigger correct behavior ..
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.
But it hasn't been fixed.
Incorrect; reread my previous statement.
You admitted it.
Incorrect.
You said that after detecting end of file using IOSTAT, you exited the loop,
and the outer loop then proceeded to execute READs on the same file.
That was before the fix. Now it is using a named DO loop, and when
the data-reading DO loop encounters the end-of-file condition, it
exits the outer DO loop, so the outer DO loop's READ statement is
not encountered. That made the value of IOSTAT in the outer DO loop
irrelevant. However, that I succeeded in making my program work
properly did not change my curiosity as to why the value of IOSTAT
changed upon the second end-of-file READ.
It was fixed before I even posted on this forum. The question is not >>>>>> how to fix the problem. The question is why the value of IOSTAT was >>>>>> changed.
That has already been explained to you.
Where? 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".
There must be some rationale.
It also tests IOSTAT to deal with the end-of-file condition,
The program has already hit the end of file.
Now you are trying to read read the same file at the same place.
That's just it: same file, same place, same action, yet a different >>>>>> IOSTAT result. Not what I had expected.
Again, that has been explained to you.
Again, where?
but
it tested for a negative number, which IOSTAT was no longer set to.
You need to avoid reading after end of file has been detected.
Why? IOSTAT was added so that a program could handle error conditions.
IOSTAT was added so that end-of-file could be detected and dealt with.
IOSTAT was also added so that error conditions could be detected.
[Note that end-of-file is not considered to be an error condition.]
But another READ past the end-of-file apparently is considered to be an
error condition by gfortran, whereas ifort apparently considers it to be
an end-of-file condition.
Provided that you deal with the condition and do not do silly things like reading
the same file again, after detecting end-of file.
Hardly silly, given that reading the same file again just triggers yet another
error condition,
No it doesn't. Reading the same file again after end of file has been detected
is the first error condition raised.
You don't know that. In fact, if you read elsewhere in this thread, you'd
know that the data file uses the characters "null" in place of a missing
numerical value, which triggers multiple error conditions long before a
second end-of-file READ occurs. It's hardly the first error condition
raised.
IOSTAT returns a negative value for end of file.
IOSTAT returns a positive integer for an error condition.
Yet ifort returns -1 for a second end-of-file READ while gfortran returns
5001. Are you arguing that one of the two compilers is not standard
compliant?
and IOSTAT was designed to allow programs to deal with the
error condition.
My program was designed to deal with the error condition. Had gfortran >>>>>> consistently returned a negative IOSTAT for every attempt to READ past >>>>>> the end-of-file, my program would have worked exactly as intended.
Listen up. Your program is in error. Fix it.
Listen up: you are incorrect.
I am not incorrect. Read the standard.
You are incorrect. My program is standard-conforming and works properly.
Since you have not read the standard, you do not know whether your program
is "standard conforming".
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 infrioation is in the standard.
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.
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.
You still have not read the standard.
However, my program *WAS* compatible
with ifort's handling of a second end-of-file READ. My program *IS* no longer
incompatible with either compiler, and that was the case before I even >>>> posted on this forum. Get your tenses straight.
Had I used ifort, my program would have worked exactly as intended.
And if you must know why the nested DO loops, one loop dealt with data >>>>>>>> while the other loop dealt with metadata. It was easily fixable. My >>>>>>>> question here was not about how to fix the problem, but rather to find >>>>>>>> out the rationale for changing the value of IOSTAT in such a situation.
My expectation was that IOSTAT would remain negative. My expectation >>>>>>>> was wrong, hence the curiosity.
On a completely separate matter, I have a different program that >>>>>>>>>> didn't behave as expected, and that misbehavior was totally repeatable.
In an attempt to debug the program, I added a WRITE statement to check
on the value of a variable during execution. However, once the WRITE >>>>>>>>>> statement was added, the program started behaving properly, repeatably.
That suggests that there is a bug in your program.
Brilliant.
Possibly something has
been overwritten.
I already thought about that, hence the WRITE statement to examine >>>>>>>> the values of the array indices.
In every program unit, subroutine and function in the entire program?
I usually sprinkle WRITE statements around to isolate where the crash >>>>>> is happening. As I narrow things down, unnecessary WRITE statements are >>>>>> either removed or commented out. In this particular case, I got it down >>>>>> to a single WRITE statement that could trigger proper behavior.Your program has errors.
Perhaps. I doubt anyone can guarantee that the optimizer has zero bugs.
It's common for people to blame the compiler when their program does not work,
especially when they do not bother to read the manual.
Hence why I wrote "It's too easy to blame the optimizer."
It wouldn't be the first time I've encountered a bug in an optimizer.
Clearly there is a bug somewhere, but you can't guarantee that it is in >>>> my code.
Can you guarantee that the bug(s) is not in your code?
Obviously not, hence my request for "generic advice on what to look for in >> such a situation."
Then why don't you act on that advice?
That advice has been given to you several times by various people.
Why continue to ask questions for which answers have already been provided?
Why do you continue to ignore the advice that you have been
given?
And keep asking the same questions?
Find them with the help of debug options
such as subscript bound errors, substring errors, and the like.
The WRITE statements showed that my subscripts are within bounds.
That's not the same as enabling subscript checks and all other checks.
It is the same as checking for subscript bound errors.
But your kind of error can be caused by many things besides
subscript errors.
Substrings are not involved.
The values were within range and
the program worked properly with the WRITE statement enabled. Comment >>>>>>>> out the WRITE statement, and the misbehavior returned. Hence the >>>>>>>> frustration.
Turn on subscript bounds checking (if available).Easier said than done, as the program was built from dozens of separately
And while you're at it, turn on all checks.
written and compiled subprograms. It has not always been obvious to me >>>>>>>> whether a compilation flag needs to be applied to every single subprogram
in order to accomplish a goal.
Obviously, program checking needs to be specified for every separate compilation,
as the apparent overwriting could be in any one or more subroutine and function.
So, you're saying that if my program has subprograms A, B, C, D, and E, >>>>>> and the crash occurs while it's executing subprogram C, the apparent >>>>>> overwriting could be in A, B, D, or E?
On Sunday, July 17, 2022 at 11:48:12 AM UTC-7, FortranFan wrote:
(snip)
"If an end-of-file condition occurs during execution of an input/output statement that contains either an END= specifier or an IOSTAT= specifier, and an error condition does not occur then:
(1) processing of the input list, if any, terminates;
(2) if the statement is a data transfer statement or the end-of-file condition occurs during a wait operation,
all do-variables in the statement that initiated the transfer become undefined;
(3) if the statement is an input statement or the end-of-file condition occurs during a wait operation
for a transfer initiated by an input statement, all effective items resulting from the expansion of list
items or the namelist group in the statement that initiated the transfer become undefined;
(4) if the file specified in the input statement is an external record file, it is positioned after the endfile record;"
Those are useful, but there are also ones that apply for I/O errors.
I believe, like (3), in the case of I/O error that all the I/O list elements are undefined.
For comparison, in C all I/O elements before EOF or any other condition occurs are
not undefined, but have the appropriate value. That can be very convenient.
<snip>
The use of WRITE statements to check on the values of variables has
served
me well for debugging purposes for decades. However, when the
addition of a
WRITE statement makes a problem go away, one wonders how that can happen.
On 7/20/2022 5:00 AM, Dave Tholen wrote:
<snip>
The use of WRITE statements to check on the values of variables has
served
me well for debugging purposes for decades. However, when the
addition of a
WRITE statement makes a problem go away, one wonders how that can happen.
Arguing with Robin isn't going to help you fix the problem.
Wondering what might have gone wrong isn't going to help.
There is a path to a solution, painful as it might be:
1. Compile your code for debug. If the problem persists, that's a good
thing. If the problem goes away, you'll have to debug whatever version
fails.
2. Find a debugger. Even a command-line debugger will do. Step through
the code. Set breakpoints. Set watchpoints. Follow the leads, the
hunches, the blind alleys. This will be time-consuming and tedious. You
will hate your life. Everyone around you will hate your life. They may
even hate you. Don't give up.
3. If the code and the data are suitable for public viewing, and if
packaging everything so someone else can have a go at it is less painful
than step 2 above, then do that. There are people out there with the requisite knowledge, experience and high tolerance for pain. When
someone figures it out, we'll all learn something.
Louis
However, when the addition of a WRITE statement makes a problem
go away, one wonders how that can happen.
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.
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".
You wrote "the" standard as if there has been only one.
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.
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,
.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.
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,
if you think it is in error. Don't be surprised
if the response is that when you read past the end-of-file, it is an end-of-file condition, regardless of the number of times you do it.
You still have not read the standard.
You are still incorrect. There are all sorts of situations that the standard >> writers did not anticipate when the standards were written, hence the need for
"interpretations" from the standards committee.
Find them with the help of debug options
such as subscript bound errors, substring errors, and the like.
The WRITE statements showed that my subscripts are within bounds.
That's not the same as enabling subscript checks and all other checks.
It is the same as checking for subscript bound errors.
But your kind of error can be caused by many things besides
subscript errors.
My WRITE statements were not limited to the display of only subscript values.
The use of WRITE statements to check on the values of variables has served
me well for debugging purposes for decades. However, when the addition of a WRITE statement makes a problem go away, one wonders how that can happen.
On 7/25/22 1:03 AM, Robin Vowels wrote:
The situation is NOT "processor dependent". The actual numerical valueCan you quote the standard, any version of the standard, that specifies
is processor dependent", but the sign of the value is NOT. The sign
is required to be positive. ifort is not standard-conforming.
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.
$.02 -Ron Shepard
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.
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.
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.
The situation is NOT "processor dependent". The actual numerical valueThe 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".
is processor dependent", but the sign of the value is NOT. The sign
is required to be positive. ifort is not standard-conforming.
On 7/25/2022 2:03 AM, Robin Vowels wrote:
The situation is NOT "processor dependent". The actual numerical valueThe 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".
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:
While it was once common practice to read past tapemarks on unlabeled magnetic tapes, that never became part of the Fortran standard.
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
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.
While it was once common practice to read past tapemarks on unlabeled magnetic tapes, that never became part of the Fortran standard.
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
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/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.
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.
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?
A good reason for using PL/I which, in 1966, treated routinely
end-of-file conditions [ ON ENDFILE (x) ... ] and error conditions
[ ON ERROR ... ]
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.
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/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/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.
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.
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).
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.
You wrote: "But once the DO loop has been exited, the program is in
an outer DO loop, which can also read the file."
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.
You wrote "the" standard as if there has been only one.
There have been a number of standards published.
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).
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.
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.
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.
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,
instead of the positive vaue that was require by the Standard.
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.
if you think it is in error. Don't be surprised
if the response is that when you read past the end-of-file, it is an
end-of-file condition, regardless of the number of times you do it.
You still have not read the standard.
The Standard requires that
a Fortran compiler to return a positive value when a program attempts
to read past the end of file.
You still have not read the standard.
You are still incorrect. There are all sorts of situations that the standard
writers did not anticipate when the standards were written, hence the need for
"interpretations" from the standards committee.
There is no need for an "interpretation". The standard is clear and unequivocal.
The standard has been around for 40 years.
Find them with the help of debug options
such as subscript bound errors, substring errors, and the like.
The WRITE statements showed that my subscripts are within bounds.
That's not the same as enabling subscript checks and all other checks.
It is the same as checking for subscript bound errors.
No it's not. You could have missed printing one critial value,
or not realized that a subscript is out-of-range.
But your kind of error can be caused by many things besides
subscript errors.
My WRITE statements were not limited to the display of only subscript values.
That's irrelevant.
The use of WRITE statements to check on the values of variables has served >> me well for debugging purposes for decades. However, when the addition of a >> WRITE statement makes a problem go away, one wonders how that can happen.
I repeat: your kind of error can be caused by many things
besides subscript errors. You need to specify options that
check for ALL errors, including subscript errors.
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.
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 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.
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.
I would find it easy enough to preprocess the file, such as:
sed "s/null//" < infile > outfile
Or maybe the generating program has an option to change this.
But yes, as a Fortran solution, reading line by line and processing the
line is often fine, too.
Many years ago (Fortran 77 days), I was reading a file something like:
READ(5,*, END=999) (X(I), Y(I), I=1,999)
and expecting the data to be read, and I to be 1 more than the pairs read. That was before I saw a copy of the standard, and only had the DEC manuals.
I even had the DEC bug report form, before learning that the standard,
and especially the DEC compilers, didn't require that.
In the case of either EOF or I/O error, what is actually stored, or the value of implied-DO variables, is undefined.
For my problem, a normal (not implied) DO fixed it, but others are
not so easy to fix.
.So, you're saying that if my program has subprograms A, B, C, D, and E,
and the crash occurs while it's executing subprogram C, the apparent
overwriting could be in A, B, D, or E?
.The error could be in any of A, B, C, D, E, and/or the main program.
Can you provide an example?.
.On a completely separate matter, I have a different program that
didn't behave as expected, and that misbehavior was totally repeatable. >>> In an attempt to debug the program, I added a WRITE statement to check >>> on the value of a variable during execution. However, once the WRITE
statement was added, the program started behaving properly, repeatably. >>> Comment out the added WRITE statement, and the program once again
misbehaves, repeatedly. Re-enable the WRITE statement, and everything >>> is once again hunky-dory. Damned frustrating. It's too easy to blame >>> the optimizer. Anybody have any generic advice on what to look for in >>> such a situation?
Remove the write statement and compile with -Wall -fcheck=all. This
might find where you are stomping on memory.
I would add -Werror. If you always compile without warnings, your life will be simpler.Oh, that's a deadly option for me. I use A LOT of implicit type conversion, such as doing a calculation internally using double precision, but saving
the result in single precision, such as
snglz = dblex * dbley
-Werror is happy if an explicit REAL() is used. For the single precision version of the real component of a double complex number, one needs to use REAL(REAL(dblecmplx)) to make -Werror happy.
.Are you suggesting that fortran-lang.discourse.group is for insight and that comp.lang.fortran is for open-ended discussions?Can you provide an example?If your interest is in gaining some insight and answers as opposed to an open-ended discussion, you may also want to post at the Fortran Discourse site:
https://fortran-lang.discourse.group/
And consider posting there first *your own small example* that illustrates what you are doing in your code.
You're assuming that the problem can be reproduced with a "small example". The program isn't small. If the simple addition of a WRITE statement can trigger correct behavior, shrinking of the task to a "small example" will lead to massive changes that more than likely will also eliminate the bug, especially if the bug is NOT in the subprogram where the crash occurs..
So, you're saying that if my program has subprograms A, B, C, D, and E, >>>> and the crash occurs while it's executing subprogram C, the apparent
overwriting could be in A, B, D, or E?
The error could be in any of A, B, C, D, E, and/or the main program.
Can you provide an example?
You already have a program that contains this kind of error.
.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.
But it hasn't been fixed.
Incorrect; reread my previous statement.
You admitted it.
Incorrect.
You said that after detecting end of file using IOSTAT, you exited the loop,
and the outer loop then proceeded to execute READs on the same file.
That was before the fix. Now it is using a named DO loop, and when
the data-reading DO loop encounters the end-of-file condition, it
exits the outer DO loop, so the outer DO loop's READ statement is
not encountered. That made the value of IOSTAT in the outer DO loop
irrelevant. However, that I succeeded in making my program work
properly did not change my curiosity as to why the value of IOSTAT
changed upon the second end-of-file READ.
It was fixed before I even posted on this forum. The question is not >>>>>> how to fix the problem. The question is why the value of IOSTAT was >>>>>> changed.
That has already been explained to you.
Where? 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".
There must be some rationale.
It also tests IOSTAT to deal with the end-of-file condition,
The program has already hit the end of file.
Now you are trying to read read the same file at the same place.
That's just it: same file, same place, same action, yet a different >>>>>> IOSTAT result. Not what I had expected.
Again, that has been explained to you.
Again, where?
but
it tested for a negative number, which IOSTAT was no longer set to.
You need to avoid reading after end of file has been detected.
[Note that end-of-file is not considered to be an error condition.]Why? IOSTAT was added so that a program could handle error conditions. >>> IOSTAT was added so that end-of-file could be detected and dealt with. >>> IOSTAT was also added so that error conditions could be detected.
But another READ past the end-of-file apparently is considered to be an
error condition by gfortran, whereas ifort apparently considers it to be >> an end-of-file condition.
Provided that you deal with the condition and do not do silly things like reading
the same file again, after detecting end-of file.
Hardly silly, given that reading the same file again just triggers yet another
error condition,
No it doesn't. Reading the same file again after end of file has been detected
is the first error condition raised.
You don't know that. In fact, if you read elsewhere in this thread, you'd >> know that the data file uses the characters "null" in place of a missing >> numerical value, which triggers multiple error conditions long before a
second end-of-file READ occurs. It's hardly the first error condition
raised.
IOSTAT returns a negative value for end of file.
IOSTAT returns a positive integer for an error condition.
Yet ifort returns -1 for a second end-of-file READ while gfortran returns >> 5001. Are you arguing that one of the two compilers is not standard
compliant?
and IOSTAT was designed to allow programs to deal with the
error condition.
My program was designed to deal with the error condition. Had gfortran >>>>>> consistently returned a negative IOSTAT for every attempt to READ past >>>>>> the end-of-file, my program would have worked exactly as intended.
Listen up. Your program is in error. Fix it.
Listen up: you are incorrect.
I am not incorrect. Read the standard.
You are incorrect. My program is standard-conforming and works properly.
Since you have not read the standard, you do not know whether your program is "standard conforming".You wrote "the" standard as if there has been only one. 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.
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).Irrelevant, given that my program does not test for specific processor-dependent
However, the value returned for end-of-file is negative.
The value for an error condition is positive.
This information is in the standard.
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.
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.
Can you provide an example?
If your interest is in gaining some insight and answers as opposed to an open-ended discussion, you may also want to post at the Fortran Discourse site:
https://fortran-lang.discourse.group/
Are you suggesting that fortran-lang.discourse.group is for insight and that
comp.lang.fortran is for open-ended discussions?
And consider posting there first *your own small example* that illustrates what you are doing in your code.
You're assuming that the problem can be reproduced with a "small example". >>> The program isn't small. If the simple addition of a WRITE statement can >>> trigger correct behavior, shrinking of the task to a "small example" will >>> lead to massive changes that more than likely will also eliminate the bug, >>> especially if the bug is NOT in the subprogram where the crash occurs.
You have already been told that the bug could be in any of your
subroutines, functions, and main program.
Irrelevant here, as the suggestion was to shrink the program to a small example. Such shrinkage could easily eliminate the alleged bug.
Can you provide an example?
If your interest is in gaining some insight and answers as opposed to an open-ended discussion, you may also want to post at the Fortran Discourse site:
https://fortran-lang.discourse.group/
Are you suggesting that fortran-lang.discourse.group is for insight and that >> comp.lang.fortran is for open-ended discussions?
And consider posting there first *your own small example* that illustrates what you are doing in your code.
You're assuming that the problem can be reproduced with a "small example". >> The program isn't small. If the simple addition of a WRITE statement can
trigger correct behavior, shrinking of the task to a "small example" will
lead to massive changes that more than likely will also eliminate the bug, >> especially if the bug is NOT in the subprogram where the crash occurs.
You have already been told that the bug could be in any of your
subroutines, functions, and main program.
Start work on that.
.Can you provide an example?So, you're saying that if my program has subprograms A, B, C, D, and E, >>>> and the crash occurs while it's executing subprogram C, the apparent >>>> overwriting could be in A, B, D, or E?The error could be in any of A, B, C, D, E, and/or the main program.
.You already have a program that contains this kind of error.
Not a useful example..
A useful example would be a program that has an
*identified* bug in A but crashes while executing C, except when a WRITE statement has been added to C to check on subscript bounds. That way, a programmer could fix the bug in A and verify that the crash in C no longer occurs, even without the WRITE statement.
.Can you provide an example?
If your interest is in gaining some insight and answers as opposed to an open-ended discussion, you may also want to post at the Fortran Discourse site:
https://fortran-lang.discourse.group/
Are you suggesting that fortran-lang.discourse.group is for insight and that
comp.lang.fortran is for open-ended discussions?
You have already been told that the bug could be in any of your subroutines, functions, and main program.And consider posting there first *your own small example* that illustrates what you are doing in your code.You're assuming that the problem can be reproduced with a "small example". >> The program isn't small. If the simple addition of a WRITE statement can >> trigger correct behavior, shrinking of the task to a "small example" will >> lead to massive changes that more than likely will also eliminate the bug, >> especially if the bug is NOT in the subprogram where the crash occurs.
Irrelevant here,.
as the suggestion was to shrink the program to a small.
example. Such shrinkage could easily eliminate the alleged bug.
Start work on that.
I had already started work on that, namely with the WRITE statements to check on the values of relevant variables, but that made the problem go away.
That.
raised the question of where next to look, given that looking at the subroutine
in which the crash occurred was fruitless. The question in this thread was for
some generic guidance as to where might be a more fruitful place to look. The best you've been able to come up with is "look everywhere".
At least others.
have recommended specific compiler options, which is far more useful.
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 inAnd what I wrote is correct. It's still correct, as one loop reads data
an outer DO loop, which can also read the file."
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.
MaybeYou haven't read the relevant standard,
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 keywordYou seem to be having trouble identifying what the issue is here. No
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).
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.
Can you provide an example?
If your interest is in gaining some insight and answers as opposed to an open-ended discussion, you may also want to post at the Fortran Discourse site:
https://fortran-lang.discourse.group/
Are you suggesting that fortran-lang.discourse.group is for insight and that
comp.lang.fortran is for open-ended discussions?
And consider posting there first *your own small example* that illustrates what you are doing in your code.
You're assuming that the problem can be reproduced with a "small example". >>>> The program isn't small. If the simple addition of a WRITE statement can >>>> trigger correct behavior, shrinking of the task to a "small example" will >>>> lead to massive changes that more than likely will also eliminate the bug, >>>> especially if the bug is NOT in the subprogram where the crash occurs.
You have already been told that the bug could be in any of your
subroutines, functions, and main program.
Irrelevant here,
It's not irrelevant.
Are you really trying to find the bug?
All you seem to be doing is arguing about it.
as the suggestion was to shrink the program to a small
example. Such shrinkage could easily eliminate the alleged bug. ------------------------------------------------------------------
Start work on that.
I had already started work on that, namely with the WRITE statements to check
on the values of relevant variables, but that made the problem go away.
That is what you wrote in your first post.
You need to do what we have suggested. Turn on all checks.
That
raised the question of where next to look, given that looking at the subroutine
in which the crash occurred was fruitless. The question in this thread was for
some generic guidance as to where might be a more fruitful place to look. The
best you've been able to come up with is "look everywhere".
A long time ago, I suggested truning on subscript checks and all other debug options.
At least others
have recommended specific compiler options, which is far more useful.
They have suggested the same as I did.
So, you're saying that if my program has subprograms A, B, C, D, and E, >>>>>> and the crash occurs while it's executing subprogram C, the apparent >>>>>> overwriting could be in A, B, D, or E?
The error could be in any of A, B, C, D, E, and/or the main program.
Can you provide an example?
You already have a program that contains this kind of error.
Not a useful example.
It's the only one that you have.
A useful example would be a program that has an
*identified* bug in A but crashes while executing C, except when a WRITE
statement has been added to C to check on subscript bounds. That way, a
programmer could fix the bug in A and verify that the crash in C no longer >> occurs, even without the WRITE statement.
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.
But it hasn't been fixed.
Incorrect; reread my previous statement.
You admitted it.
Incorrect.
You said that after detecting end of file using IOSTAT, you exited the loop,
and the outer loop then proceeded to execute READs on the same file.
That was before the fix. Now it is using a named DO loop, and when >>>>>> the data-reading DO loop encounters the end-of-file condition, it
exits the outer DO loop, so the outer DO loop's READ statement is
not encountered. That made the value of IOSTAT in the outer DO loop >>>>>> irrelevant. However, that I succeeded in making my program work
properly did not change my curiosity as to why the value of IOSTAT >>>>>> changed upon the second end-of-file READ.
It was fixed before I even posted on this forum. The question is not >>>>>>>> how to fix the problem. The question is why the value of IOSTAT was >>>>>>>> changed.
That has already been explained to you.
Where? 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".
There must be some rationale.
It also tests IOSTAT to deal with the end-of-file condition,
The program has already hit the end of file.
Now you are trying to read read the same file at the same place.
That's just it: same file, same place, same action, yet a different >>>>>>>> IOSTAT result. Not what I had expected.
Again, that has been explained to you.
Again, where?
but
it tested for a negative number, which IOSTAT was no longer set to.
You need to avoid reading after end of file has been detected.
[Note that end-of-file is not considered to be an error condition.]Why? IOSTAT was added so that a program could handle error conditions. >>>>> IOSTAT was added so that end-of-file could be detected and dealt with. >>>>> IOSTAT was also added so that error conditions could be detected.
But another READ past the end-of-file apparently is considered to be an >>>> error condition by gfortran, whereas ifort apparently considers it to be >>>> an end-of-file condition.
Provided that you deal with the condition and do not do silly things like reading
the same file again, after detecting end-of file.
Hardly silly, given that reading the same file again just triggers yet another
error condition,
No it doesn't. Reading the same file again after end of file has been detected
is the first error condition raised.
You don't know that. In fact, if you read elsewhere in this thread, you'd >>>> know that the data file uses the characters "null" in place of a missing >>>> numerical value, which triggers multiple error conditions long before a >>>> second end-of-file READ occurs. It's hardly the first error condition
raised.
IOSTAT returns a negative value for end of file.
IOSTAT returns a positive integer for an error condition.
Yet ifort returns -1 for a second end-of-file READ while gfortran returns >>>> 5001. Are you arguing that one of the two compilers is not standard
compliant?
and IOSTAT was designed to allow programs to deal with the
error condition.
My program was designed to deal with the error condition. Had gfortran >>>>>>>> consistently returned a negative IOSTAT for every attempt to READ past >>>>>>>> the end-of-file, my program would have worked exactly as intended.
Listen up. Your program is in error. Fix it.
Listen up: you are incorrect.
I am not incorrect. Read the standard.
You are incorrect. My program is standard-conforming and works properly.
Since you have not read the standard, you do not know whether your program >>> is "standard conforming".
You wrote "the" standard as if there has been only one. 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.
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, 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.
The feature in question is NOT a processor-dependent feature.
Your program tested for a negative value when it should have tested for a positive value.
Your program was wrong.
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.
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
The standard is clear and unequivocal. I quoted it in this thread.
The last record has been read. Reading again returns a negative
value in IOSTAT, indicating end-of-file.
Reading again is an error, and IOSTAT yields a positive value,
indicating an error.
or an
error condition. It's situations like this one that often trigger an
"interpretation" of the standard by the standards committee.
You are in fairy land.
The standard of 1977 introduced IOSTAT and specified what happens.
That hasn't changed since.
In 44 years there has not been "clarification" because none was needed.
Read the standard, and move on.
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.
You haven't read the relevant standard,
or you wouldn't be still arguing about fanciful possibilities.
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.
Listen up. It is an error to try to read the file after you have already received
an end-of-file.
You get an ERROR indication via IOSTAT..
If you keep ignoring the error condition, your program can get into a loop.
have been multiple Fortran standards. I have a hardcopy of one of the
earlier standards and have read it.
Which one is that?
Are you really trying to find the bug?
When I have the time to do so. The problem hasn't occurred in any recent use of the program, so it hasn't been a priority.
.Are you really trying to find the bug?
When I have the time to do so. The problem hasn't occurred in any recent.
use of the program, so it hasn't been a priority.
.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
The standard is clear and unequivocal. I quoted it in this thread.So has Robert Corbett:
"Subclause 12.11.1 of the Fortran 2018 standard states
The set of input/output error conditions is
processor dependent."
Gee, I've been saying repeatedly that the situation is processor
dependent,
while you claimed (several lines above) "The situation.
is NOT 'processor dependent'". Looks like the 2018 standard agrees
with me.
Are you seriously trying to suggest that the Fortran standards have.
all been written so well that no interpretations have ever been issued
by the standards committee?
.The standard of 1977 introduced IOSTAT and specified what happens.
That hasn't changed since.
In 44 years there has not been "clarification" because none was needed.
You need to read the contributions of others in this thread. All sorts.
of "clarifications" have been made.
.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
The standard is clear and unequivocal. I quoted it in this thread.So has Robert Corbett:
"Subclause 12.11.1 of the Fortran 2018 standard states
The set of input/output error conditions is
processor dependent."
Gee, I've been saying repeatedly that the situation is processor
dependent, while you claimed (several lines above) "The situation
is NOT 'processor dependent'". Looks like the 2018 standard agrees
with me.
The last record has been read. Reading again returns a negativeHello??? I wrote in my original post that the IOSTAT value is 5001
value in IOSTAT, indicating end-of-file.
Reading again is an error, and IOSTAT yields a positive value,
indicating an error.
when the second READ is attempted, so all you just did was to repeat
what I've known from the beginning of this thread.
or an
error condition. It's situations like this one that often trigger an
"interpretation" of the standard by the standards committee.
You are in fairy land.Are you seriously trying to suggest that the Fortran standards have
all been written so well that no interpretations have ever been issued
by the standards committee?
The standard of 1977 introduced IOSTAT and specified what happens.You need to read the contributions of others in this thread. All sorts
That hasn't changed since.
In 44 years there has not been "clarification" because none was needed.
of "clarifications" have been made. At the risk of repetition:
"Subclause 12.11.1 of the Fortran 2018 standard states
The set of input/output error conditions is
processor dependent."
Read the standard, and move on.Follow your own advice.
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.
You haven't read the relevant standard,How would you know what the relevant standard is? Was my program written
or you wouldn't be still arguing about fanciful possibilities.
to the Fortran 2003 standard? Or was it written to the Fortran 95 standard? Or maybe the Fortran 90 standard? Perhaps even the Fortran 77 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.
Listen up. It is an error to try to read the file after you have already receivedListen up. I wrote in the original post that the IOSTAT value is 5001 after an end-of-file has been encountered, hence I've known from the beginning of this thread that gfortran treated it as an error condition. Why do you keep repeating what has been noted from the beginning of this thread?
an end-of-file.
You get an ERROR indication via IOSTAT..Irrelevant, given that my program doesn't keep ignoring the error condition. >>>> In reality, there
If you keep ignoring the error condition, your program can get into a loop.
have been multiple Fortran standards. I have a hardcopy of one of the >>>> earlier standards and have read it.
Which one is that?
The relevant one..
Are you really trying to find the bug?
When I have the time to do so. The problem hasn't occurred in any recent
use of the program, so it hasn't been a priority.
Your particular complaint was that the program failed when a
print statement is inserted in it.
The error is still there.
As such an error is typical of a program that has overwritten itself,
how can you be sure that your program is even getting the correct answers?
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
The standard is clear and unequivocal. I quoted it in this thread.
So has Robert Corbett:
"Subclause 12.11.1 of the Fortran 2018 standard states
The set of input/output error conditions is
processor dependent."
Gee, I've been saying repeatedly that the situation is processor
dependent, while you claimed (several lines above) "The situation
is NOT 'processor dependent'". Looks like the 2018 standard agrees
with me.
The last record has been read. Reading again returns a negative
value in IOSTAT, indicating end-of-file.
Reading again is an error, and IOSTAT yields a positive value,
indicating an error.
Hello??? I wrote in my original post that the IOSTAT value is 5001
when the second READ is attempted, so all you just did was to repeat
what I've known from the beginning of this thread.
or an
error condition. It's situations like this one that often trigger an
"interpretation" of the standard by the standards committee.
You are in fairy land.
Are you seriously trying to suggest that the Fortran standards have
all been written so well that no interpretations have ever been issued
by the standards committee?
The standard of 1977 introduced IOSTAT and specified what happens.
That hasn't changed since.
In 44 years there has not been "clarification" because none was needed.
You need to read the contributions of others in this thread. All sorts
of "clarifications" have been made. At the risk of repetition:
"Subclause 12.11.1 of the Fortran 2018 standard states
The set of input/output error conditions is
processor dependent."
Read the standard, and move on.
Follow your own advice.
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.
You haven't read the relevant standard,How would you know what the relevant standard is? Was my program written
or you wouldn't be still arguing about fanciful possibilities.
to the Fortran 2003 standard? Or was it written to the Fortran 95 standard? >> Or maybe the Fortran 90 standard? Perhaps even the Fortran 77 standard?
Had you read these standards, you would have found that they all specify the same thing
for the treatment of end-of-file and for errors, and the values that
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.
Listen up. It is an error to try to read the file after you have already received
an end-of-file.
Listen up. I wrote in the original post that the IOSTAT value is 5001 after >> an end-of-file has been encountered, hence I've known from the beginning of >> this thread that gfortran treated it as an error condition. Why do you keep >> repeating what has been noted from the beginning of this thread?
You get an ERROR indication via IOSTAT..
If you keep ignoring the error condition, your program can get into a loop.
Irrelevant, given that my program doesn't keep ignoring the error condition.
In reality, there
have been multiple Fortran standards. I have a hardcopy of one of the >>>>>> earlier standards and have read it.
Which one is that?
The relevant one.
You are being evasive.
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
The standard is clear and unequivocal. I quoted it in this thread.
So has Robert Corbett:
"Subclause 12.11.1 of the Fortran 2018 standard states
The set of input/output error conditions is
processor dependent."
Gee, I've been saying repeatedly that the situation is processor
dependent,
You are confused.
The treatment of end-of-file and of error conditions is NOT, repeat NOT processor-dependent.
It is clearly stated in all the standards since FORTRAN 77.
It is the magnitude of the numerical value returned by IOSTAT
that is processor-dependent (except for the value zero, which is returned when there is neither an end-of-file encountered nor an error occurs).
The value of zero is NOT processor dependent.
while you claimed (several lines above) "The situation
is NOT 'processor dependent'". Looks like the 2018 standard agrees
with me.
The 2018 standard does not agree with you.
Are you seriously trying to suggest that the Fortran standards have
all been written so well that no interpretations have ever been issued
by the standards committee?
You are being ridiculous.
I said that no clarifications for IOSTAT have been issued.
In fact, if you read 12.11.5 of the 2018 Fortran standard,
you will find an example that will help you understand how to make use of IOSTAT.
The standard of 1977 introduced IOSTAT and specified what happens.
That hasn't changed since.
In 44 years there has not been "clarification" because none was needed.
You need to read the contributions of others in this thread. All sorts
of "clarifications" have been made.
You are being silly.
These are not clarifications by the standards committee.
<snip>
Are you really trying to find the bug?
When I have the time to do so. The problem hasn't occurred in any recent >> use of the program, so it hasn't been a priority.
I can see some risk in that approach.
While you're not seeing the bug's most obvious manifestation, you don't know if it's dropping
a random value in a random place in memory. That can be harmless ... until it's not.
It sounded, at least when you first posted, like you had a mysterious bug that you could reproduce. There are maintenance
programmers out there who would be thrilled to work on a bug like that. It offers a challenge and an unknown payback: Going into it,
you don't know what's not going to go wrong once the bug is fixed.
When I was working, I lived for bugs like this. I'd come in to the office late and I'd sit there with a cup of tea and a chocolate
bar and Bruckner's 7th Symphony on my boombox and I'd crank up the volume and there was nobody around to complain and I'd lose track
of time and once in a while I'd walk around and see if the sun was up (management didn't usually give window offices to people who
liked to work at night) and by the time the normal people rolled in around 8:00 AM I'd at least have a handle on what was going
wrong and I could share the details with colleagues who were interested and a few who weren't and then I'd go home and try to get
some rest, secure in the knowledge that I'd done my bit and that if nobody saw me again until the next day they wouldn't miss me
because have you ever actually listened to Bruckner?
.Incorrect.Your particular complaint was that the program failed when aAre you really trying to find the bug?When I have the time to do so. The problem hasn't occurred in any recent >> use of the program, so it hasn't been a priority.
print statement is inserted in it.
And now I understand what your problem is. Some sort of.
dyslexic reading. In fact, my particular complaint was just the opposite: adding a WRITE statement made the problem disappear.
The error is still there.
But if the feature isn't used, the error doesn't manifest itself..
.As such an error is typical of a program that has overwritten itself,
how can you be sure that your program is even getting the correct answers?
The same way that someone programming an image manipulation program would know: if the sky started out blue and remained that way after manipulation..
Are you really trying to find the bug?
When I have the time to do so. The problem hasn't occurred in any recent >>>> use of the program, so it hasn't been a priority.
Your particular complaint was that the program failed when a
print statement is inserted in it.
Incorrect.
You don't say.
Whether the error manifests itself when you insert an innocuous statement such as a WRITE statement, or remove it, is irrelevant.
The fact is the program exhibits symptoms of corrupting itself (that is,
of overwriting itself).
And you were trying to debug the program by inserting a WRITE statement.
So you knew that there was a bug somewhere.
And now I understand what your problem is. Some sort of
dyslexic reading. In fact, my particular complaint was just the opposite:
adding a WRITE statement made the problem disappear.
The error is still there.
But if the feature isn't used, the error doesn't manifest itself.
So what? The error is still evident.
As such an error is typical of a program that has overwritten itself,
how can you be sure that your program is even getting the correct answers?
The same way that someone programming an image manipulation program would
know: if the sky started out blue and remained that way after manipulation.
All irrelevant.
You have no idea what to expect when the program runs when there is a bug somewhere.
.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
The standard is clear and unequivocal. I quoted it in this thread.
So has Robert Corbett:
"Subclause 12.11.1 of the Fortran 2018 standard states
The set of input/output error conditions is
processor dependent."
.Gee, I've been saying repeatedly that the situation is processor
dependent,
.You are confused.
Incorrect.
.The treatment of end-of-file and of error conditions is NOT, repeat NOT processor-dependent."Subclause 12.11.1 of the Fortran 2018 standard states
The set of input/output error conditions is
processor dependent."
.It is clearly stated in all the standards since FORTRAN 77."Subclause 12.11.1 of the Fortran 2018 standard states
It is the magnitude of the numerical value returned by IOSTAT
that is processor-dependent (except for the value zero, which is returned when there is neither an end-of-file encountered nor an error occurs).
The set of input/output error conditions is
processor dependent."
Says absolutely nothing about the values returned by IOSTAT..
Rather, it talks about the set of error conditions. Conditions,.
not values. Got it?
.The value of zero is NOT processor dependent.Irrelevant, given that I never claimed that the value of zero is
processor dependent.
"Subclause 12.11.1 of the Fortran 2018 standard stateswhile you claimed (several lines above) "The situationThe 2018 standard does not agree with you.
is NOT 'processor dependent'". Looks like the 2018 standard agrees
with me.
The set of input/output error conditions is
processor dependent."
.Are you seriously trying to suggest that the Fortran standards haveYou are being ridiculous.
all been written so well that no interpretations have ever been issued
by the standards committee?
I see that you failed to answer the question.
.I said that no clarifications for IOSTAT have been issued.
Perhaps. Has the committee even met since this issue was raised?.
Note that.
Steve Lionel discussed the issue with Malcolm Cohen of NAG. Sounds like
one person got an informal interpretation from another person.
In fact, if you read 12.11.5 of the 2018 Fortran standard,
you will find an example that will help you understand how to make use of IOSTAT.
I already understand how to make use of IOSTAT..
.You are being silly.The standard of 1977 introduced IOSTAT and specified what happens.of "clarifications" have been made.
That hasn't changed since.
In 44 years there has not been "clarification" because none was needed. >> You need to read the contributions of others in this thread. All sorts
That Steve Lionel talked to Malcolm Cohen is a fact, not silliness.
These are not clarifications by the standards committee.Irrelevant, given that I never claimed that they are.
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
The standard is clear and unequivocal. I quoted it in this thread.
So has Robert Corbett:
"Subclause 12.11.1 of the Fortran 2018 standard states
The set of input/output error conditions is
processor dependent."
It says more than that.
You have misleadingly truncated what he quoted.
"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."
[see the remainder of 12.11.1 for the details.]
Gee, I've been saying repeatedly that the situation is processor
dependent,
No,
you are not only still confused,
12.11.1 has nothing to do with your end-of-file problem --
which I and have repeatedly tried to point out to you.
You are confused.
Incorrect.
See above.
The treatment of end-of-file and of error conditions is NOT, repeat NOT processor-dependent.
"Subclause 12.11.1 of the Fortran 2018 standard states
The set of input/output error conditions is
processor dependent."
Is that a parrot still talking?
It is clearly stated in all the standards since FORTRAN 77.
It is the magnitude of the numerical value returned by IOSTAT
that is processor-dependent (except for the value zero, which is returned >>> when there is neither an end-of-file encountered nor an error occurs).
"Subclause 12.11.1 of the Fortran 2018 standard states
The set of input/output error conditions is
processor dependent."
Still a parrot talking.
Says absolutely nothing about the values returned by IOSTAT.
You need to read 12.11.5.
Rather, it talks about the set of error conditions. Conditions,
not values. Got it?
It also says what the exceptions are.
The value of zero is NOT processor dependent.
Irrelevant, given that I never claimed that the value of zero is
processor dependent.
while you claimed (several lines above) "The situation
is NOT 'processor dependent'". Looks like the 2018 standard agrees
with me.
The 2018 standard does not agree with you.
"Subclause 12.11.1 of the Fortran 2018 standard states
The set of input/output error conditions is
processor dependent."
Is this the same parrot, or another one?
You have lost the plot completely.
This has nothing to do with your end-of-file problem.
You need to check what happens when end-of-file is detected,
and why you got an error when you tried to read the same file
AFTER you got end-of-file.
Are you seriously trying to suggest that the Fortran standards have
all been written so well that no interpretations have ever been issued >>>> by the standards committee?
You are being ridiculous.
I see that you failed to answer the question.
I already answered that in an earlier post.
I said that no clarifications for IOSTAT have been issued.
Perhaps. Has the committee even met since this issue was raised?
You are saying that they did not meet in the last 40 years.
You are being absurd.
Note that
Steve Lionel discussed the issue with Malcolm Cohen of NAG. Sounds like
one person got an informal interpretation from another person.
In fact, if you read 12.11.5 of the 2018 Fortran standard,
you will find an example that will help you understand how to make use of IOSTAT.
I already understand how to make use of IOSTAT.
About time.
The standard of 1977 introduced IOSTAT and specified what happens.
That hasn't changed since.
In 44 years there has not been "clarification" because none was needed.
You need to read the contributions of others in this thread. All sorts >>>> of "clarifications" have been made.
You are being silly.
That Steve Lionel talked to Malcolm Cohen is a fact, not silliness.
These are not clarifications by the standards committee.
Irrelevant, given that I never claimed that they are.
You claimed that they were "clarifications".
I claimed that they are NOT clarifications by the standards committee.
<snip>
Are you really trying to find the bug?
When I have the time to do so. The problem hasn't occurred in any
recent
use of the program, so it hasn't been a priority.
I can see some risk in that approach.
It's not a matter of risk assessment. This program is strictly used in a hobby setting. There can be lengthy stretches of time when I simply
don't
have the time to pursue the hobby. When I do have the time, that time is usually split between adding capabilities to the program and using the existing capabilities of the program. Out of the dozens of functions provided by the program, there is one that is known to cause the program
to crash under certain conditions. Repeatably. Unless a WRITE statement is added in one particular spot. Then it's fine. Annoying, but
finding out
why isn't at the top of the priority list at the moment.
By way of analogy, there was a time when Microsoft's "GSA Certified to be Correct and Complete" Fortran compiler failed to run a DO loop properly
if the step size was a variable:
ISTEP = 15
DO I=0,90,ISTEP
I reported the bug, and Microsoft acknowledged the bug. In the next
release of the compiler, was it fixed? No. They were too busy adding
new features to satisfy the many rather than fixing bugs to satisfy the one. You and I might not agree with that approach. Depends on the type
of risk you're willing to take. One approach risked having a buggy
compiler whose reputation might suffer enough to adversely affect sales, while the other approach risked adding new features that would appeal to
a larger potential customer base and make more money. It's a gamble.
In my case, it's not like a spacecraft will crash into the surface of
Mars
if I don't find the bug.
While you're not seeing the bug's most obvious manifestation, you
don't know if it's dropping a random value in a random place in
memory. That can be harmless ... until it's not.
Hypothetical example: if I were writing an image manipulation
program, and
one feature was to crop the size of the image, and the cropping caused
the
program to crash, unless a WRITE statement was added to a particular spot
in a subroutine, simple inspection of the cropped photo might reveal that
the bug is harmless. Now, if the blue sky turned green in the cropped photo, then the bug isn't harmless. But the original photo is still
there,
unaffected.
It sounded, at least when you first posted, like you had a mysterious
bug that you could reproduce. There are maintenance programmers out
there who would be thrilled to work on a bug like that. It offers a
challenge and an unknown payback: Going into it, you don't know
what's not going to go wrong once the bug is fixed.
Yes, the crash was absolutely reproducible. Yes, the addition of a WRITE statement made the problem go away, which was fairly mysterious.
When I was working, I lived for bugs like this. I'd come in to the
office late and I'd sit there with a cup of tea and a chocolate bar
and Bruckner's 7th Symphony on my boombox and I'd crank up the volume
and there was nobody around to complain and I'd lose track of time
and once in a while I'd walk around and see if the sun was up
(management didn't usually give window offices to people who liked to
work at night) and by the time the normal people rolled in around
8:00 AM I'd at least have a handle on what was going wrong and I
could share the details with colleagues who were interested and a few
who weren't and then I'd go home and try to get some rest, secure in
the knowledge that I'd done my bit and that if nobody saw me again
until the next day they wouldn't miss me because have you ever
actually listened to Bruckner?
I have nine Bruckner CDs in my collection (Symphonies 4 through 9). I
have at least one musician friend who insists that once you're heard a Bruckner symphony, you've heard them all. Lately, however, I've been listening primarily to other composers. In particular, the "Shout"
movement from Omar Thomas' "Come Sunday" has captured my fancy, but it's
the Baylor rendition that brings it to life. The energy, the sheer joy
of music-making, on full display.
<snip>
Are you really trying to find the bug?
When I have the time to do so. The problem hasn't occurred in any recent >>>> use of the program, so it hasn't been a priority.
I can see some risk in that approach.
It's not a matter of risk assessment. This program is strictly used in a >> hobby setting. There can be lengthy stretches of time when I simply don't >> have the time to pursue the hobby. When I do have the time, that time is >> usually split between adding capabilities to the program and using the
existing capabilities of the program. Out of the dozens of functions
provided by the program, there is one that is known to cause the program
to crash under certain conditions. Repeatably. Unless a WRITE statement >> is added in one particular spot. Then it's fine. Annoying, but finding out
why isn't at the top of the priority list at the moment.
By way of analogy, there was a time when Microsoft's "GSA Certified to be
Correct and Complete" Fortran compiler failed to run a DO loop properly
if the step size was a variable:
ISTEP = 15
DO I=0,90,ISTEP
I reported the bug, and Microsoft acknowledged the bug. In the next
release of the compiler, was it fixed? No. They were too busy adding
new features to satisfy the many rather than fixing bugs to satisfy the
one. You and I might not agree with that approach. Depends on the type >> of risk you're willing to take. One approach risked having a buggy
compiler whose reputation might suffer enough to adversely affect sales,
while the other approach risked adding new features that would appeal to
a larger potential customer base and make more money. It's a gamble.
In my case, it's not like a spacecraft will crash into the surface of Mars >> if I don't find the bug.
While you're not seeing the bug's most obvious manifestation, you don't know if it's dropping a random value in a random place in
memory. That can be harmless ... until it's not.
Hypothetical example: if I were writing an image manipulation program, and >> one feature was to crop the size of the image, and the cropping caused the >> program to crash, unless a WRITE statement was added to a particular spot
in a subroutine, simple inspection of the cropped photo might reveal that
the bug is harmless. Now, if the blue sky turned green in the cropped
photo, then the bug isn't harmless. But the original photo is still there, >> unaffected.
It sounded, at least when you first posted, like you had a mysterious bug that you could reproduce. There are maintenance
programmers out there who would be thrilled to work on a bug like that. It offers a challenge and an unknown payback: Going into
it, you don't know what's not going to go wrong once the bug is fixed.
Yes, the crash was absolutely reproducible. Yes, the addition of a WRITE >> statement made the problem go away, which was fairly mysterious.
When I was working, I lived for bugs like this. I'd come in to the office late and I'd sit there with a cup of tea and a
chocolate bar and Bruckner's 7th Symphony on my boombox and I'd crank up the volume and there was nobody around to complain and
I'd lose track of time and once in a while I'd walk around and see if the sun was up (management didn't usually give window
offices to people who liked to work at night) and by the time the normal people rolled in around 8:00 AM I'd at least have a
handle on what was going wrong and I could share the details with colleagues who were interested and a few who weren't and then
I'd go home and try to get some rest, secure in the knowledge that I'd done my bit and that if nobody saw me again until the next
day they wouldn't miss me because have you ever actually listened to Bruckner?
I have nine Bruckner CDs in my collection (Symphonies 4 through 9). I
have at least one musician friend who insists that once you're heard a
Bruckner symphony, you've heard them all. Lately, however, I've been
listening primarily to other composers. In particular, the "Shout"
movement from Omar Thomas' "Come Sunday" has captured my fancy, but it's
the Baylor rendition that brings it to life. The energy, the sheer joy
of music-making, on full display.
I would join you in disagreeing with your friend; Bruckner symphonies are not all alike. There's the seventh, and there's everything
else. OK, maybe the seventh and the eighth, and everything else. OK, I'm being facetious.
As far as your program goes, here's one way to identify the bug and assess its potential impact: Upload the code and some test data,
and let some of us nerds (a few of us are retired with too much time on hands) try to reproduce the crash in our own environments
(mine is Fedora with gfortran) and hopefully figure out what's going on. If it's a hobby project, you might not need a formal NDA,
but you could still ask for common courtesy and discretion and so on. You could share the upload link with everyone or with
individuals.
As far as Microsoft and their DO-loop bug, I'm tempted to be appalled, but there are a couple of things to consider:
How long was the interval between your bug report and the next release?
If the release had passed the code-freeze point and the bug
wasn't a regression caused by something new in the release, I could understand why they wouldn't want to delay the release until the
bug could be fixed and the fix could be verified. The new release could have fixed a number of other bugs, and it might have done
more than just add new features.
Was the bug fixed eventually?
I can't imagine letting something like that stay broken past the next maintenance release.
At my last job, I worked on embedded code that ran inside laser printers. The tolerance for bugs was zero.
I also listened to Mahler symphonies late at night.
<snip>
As far as your program goes, here's one way to identify the bug and
assess its potential impact: Upload the code and some test data, and
let some of us nerds (a few of us are retired with too much time on
hands) try to reproduce the crash in our own environments (mine is
Fedora with gfortran) and hopefully figure out what's going on. If
it's a hobby project, you might not need a formal NDA, but you could
still ask for common courtesy and discretion and so on. You could
share the upload link with everyone or with individuals.
There are calls to specific Windows APIs, so it would take considerable modification to run on Fedora. Also, there is at least one subroutine
that uses a self-modified version of a Numerical Recipes code, which is protected by copyright, at least the parts that I didn't modify. So I
doubt I'll go your suggested route anytime soon.
<snip>
I also listened to Mahler symphonies late at night.
My Mahler collection is larger than my Bruckner collection, well over
a dozen sets,
including multiple two-disc releases.
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 159 |
| Nodes: | 16 (0 / 16) |
| Uptime: | 97:56:46 |
| Calls: | 3,209 |
| Files: | 10,563 |
| Messages: | 3,009,574 |