Re: [patch, libfortran] Handle missing EOR marker when reading

[Tobias Burnus <burnus at net-b dot de>]

Jerry DeLisle wrote:
> After reviewing the F2003 standard and the relevant clauses I am
> convinced that the standard is not "silent" on this case mentioned in
> the thread.

I disagree: The standard does not clearly say how a record marker looks
like and keeps other things as implementation defined. However, I think
your interpretation is a sensible extension of the standard into the
undefined part.

> Summarizing the case, the input file contains:
> Line-1<EOR>
> Line-2<EOF>
> 
> GFortran currently does the following:
> 
> IOSTAT_EOR(-2), Zero      (0), IOSTAT_END(-1)
> 
> I believe this is wrong 

I think the ZERO is really unexpected.

> and that we should give the following.
> IOSTAT_EOR(-2), IOSTAT_EOR(-2), IOSTAT_END(-1)

I agree that this is sensible and what I expect (and what g95, ifort,
openf95, pathscale give). NAG gives EOR, EOF, EOF which I think is also
covered by the standard.

Using pad='no', ifort still gives EOR,EOR,END while NAG gives still
EOR,EOF,EOF. However, given the standard I prefer EOR,EOF,EOF as your
patch gives.

> Regression tested on x86-64.
> OK for trunk?

OK (independent whether it is required by the standard or "just" a
sensible choice for undefined behaviour.)
Thanks for your patch!


> I will add the testcase to the testsuite if this is
> approved.

Can you check the iostat in the test case?


> Shall I capture this in a PR as well?

I think that's not needed as one can still go back to the mailing list
based on the check-in date. But if you think it makes it easier for the
future: Go ahead and fill a PR.

Tobias