This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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

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.

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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]