This is the mail archive of the gcc-patches@gcc.gnu.org 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


Tobias Burnus wrote:
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?


Yes, I will create the file status="scratch" in the test suite, test each condition with PAD="yes" , rewind, and test with PAD="no".

Thanks for review.

Jerry


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