On Monday, August 29, 2022 at 9:43:21 PM UTC+10, Dave Tholen wrote:
> >>>>>>>>> The closest anyone has come is Steve Lionel, who said he could
> >>>>>>>>> make an argument for the second instance not being -1, but he didn't
> >>>>>>>>> present that argument. That ifort returns -1 upon a second READ
> >>>>>>>>> demonstrates that the situation is "processor dependent".
>
> >>>>> The situation is NOT "processor dependent". The actual numerical value
> >>>>> is processor dependent", but the sign of the value is NOT. The sign
> >>>>> is required to be positive. ifort is not standard-conforming.
>
> >>>> 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.

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

Of course. So what? An extensive discussion of edit descriptors isn't
relevant to the matter at hand. Neither is a discussion of data types.
Or array syntax, for that matter.

> You have misleadingly truncated what he quoted.

Incorrect.

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

"It says more than that."

But BOTH sentences you quoted include the same "processor dependent"
aspect that I've maintained is the case for some time now. How can it
possibly be "misleadingly truncated" when your more extended quotation
simply reuses "processor dependent", which supports my case?

>>>> Gee, I've been saying repeatedly that the situation is processor
>>>> dependent,

> No,

Again, incorrect.

> you are not only still confused,

Ironic, coming from the one who is confused.

> 12.11.1 has nothing to do with your end-of-file problem --

An IOSTAT value of 5001 is NOT an "end-of-file problem". See what I
mean about you being the one who is confused?

> which I and have repeatedly tried to point out to you.

You keep claiming that the situation is not processor dependent, yet
your own ostensibly less misleading more extensive quotation uses
"processor dependent" twice, which hardly supports your argument.

>>> You are confused.

>> Incorrect.

> See above.

Indeed, see above for the evidence of your confusion.

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

Hearing voices in your head?

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

How many parrots do you need before you'll understand what they're telling you?

>> Says absolutely nothing about the values returned by IOSTAT.

> You need to read 12.11.5.

You need to understand 12.11.1. You need to comprehend that the set of
error conditions, which is processor dependent, is the issue here, not
the choice of positive numerical value of IOSTAT, which is what your
attempt to bring 12.11.5 into this does.

>> Rather, it talks about the set of error conditions. Conditions,
>> not values. Got it?

> It also says what the exceptions are.

Having trouble finding the relevant one?

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

Now it's the talking dog from the Apoquel television commercials, obviously.

> You have lost the plot completely.

Incorrect.

> This has nothing to do with your end-of-file problem.

An IOSTAT value of 5001 is NOT an "end-of-file problem". See what I
mean about you being the one who is confused?

> You need to check what happens when end-of-file is detected,

If you had bothered to comprehend what I wrote in the original posting,
you'd already know that I already checked what happens with end-of-file
is detected. IOSTAT is set to -1. Just like the way it was decades ago.

> and why you got an error when you tried to read the same file
> AFTER you got end-of-file.

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

Gee, what I've said for some time now.

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

No, you didn't.

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

Not even close to being true.

> You are being absurd.

If only you didn't have to make stuff up in a feeble attempt to justify
such a ridiculous claim.

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

Your concept of time is absurd. Read the first post in this thread.

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

Once again, incorrect.

> I claimed that they are NOT clarifications by the standards committee.

Ambiguous, as your usage of "they" wasn't clarified. Maybe the standards
committee can help you with your clarifications.

On 8/29/2022 6:18 AM, Dave Tholen wrote:
>> <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.

Louis

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

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.

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

Long enough.

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

Not to my recollection.

> I can't imagine letting something like that stay broken past the next maintenance release.

Ah, but Microsoft eventually decided to get out of the Fortran compiler business.
It's been a VERY long time, but if memory serves, it was Microsoft Fortran Powerstation
version 4.0 that was widely advertised to be "GSA Certified to be Correct and Complete",
but certainly wasn't correct about its handling of DO loops. If I dig through old
archives of floppy discs, I might refresh my memory as to how far it got before Microsoft
dropped the product in favor of DEC's compiler. Maybe version 5.1? It might have been
through versions 4.0, 4.1, 5.0, and 5.1, but that was a LONG time ago and memories are
fuzzy.

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

My Mahler collection is larger than my Bruckner collection, well over a dozen sets,
including multiple two-disc releases.

On 8/30/2022 6:45 PM, Dave Tholen wrote:
> <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.

You could upload whatever source code you can legally share, as long as
that includes an annotated copy of the routine where the problem
appears. There's a diminished chance that anyone will be able to help
you without being able to build and run the full application, but you
never know.

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

After listening to classical music (in the broad sense of the term) in
the initial stages of nocturnal debugging, I would often switch to
Celtic folk rock to help me stay awake. I've always enjoyed it. Your
mileage may vary.

Louis