Re: Need interpretation

Richard E Maine wrote: 
Jerry DeLisle <jvdelisle@xxxxxxxxxxx> wrote:


Which is the correct behavior here?: 


  [code elided]


gfortran and ifort give different results with those two lines commented
out.  I am trying to determine if I have a bug here or not.



The important part of the code is that it hits and end-of-file and then
tries to read again, using a read statement with an end=, but no err= or
iostat=.

This was discussed here recently... I think it was here, though it might
have been the comp-fortran-90 list. Anyway...

Strictly speaking, the code is nonstandard and the compilers are allowed
to do anything.  All quotes from f2003, but this stuff hasn't changed in
substance in ages.

[216:34] The set of input/output error conditions is processor
dependent.

That's a fundamental and important one. If the standard places an
I/O-related restriction on the user, it is the compiler's choice whether
to treat a violation of such a restriction as an error condition,
reportable by iostat= and err=, or to do something completely different
- perhaps considering it to be some extension or maybe even calling it
and eof condition. Yes, the compiler could return an eof condition for
something completely "strange" such as an improperly formatted input
field. I'd think that a darn queer way for a compiler to behave, but
strictly speaking, that wouldn't make the compiler non-conforming.

[176:12-13] If the file contains an endfile record, the file shall not
be positioned after the endfile record prior to data transfer.

That's the condition this code violates. Note that the standard just
says "shall not". That means the code is illegal. Now I personally
happen to think that it would be "proper" for the compiler to report
this as an error condition, but the standard doesn't demand that.

In case you wonder, by the way, yes your file has an endfile record. I
don't care whether or not that endfile record has a physical
manifestation in the file. As far as the Fortran standard is concerned,
the file has an endfile record. That's because of

[172:10-13] And endfile record is written implicitly to a file connected
for sequential access when the most recent data transfer statement
referring to the file is a data transfer output statement, no
intervening file positioning statement referring to the file has been
executed, and (1) A REWIND or BACKSPACE statement references the unit to
which the file is connected or...".

Note also that many people mis-quote (or mostly, don't even look at) the
standard's definition of an end-of-file condition. For a sequential
file, an end-of-file condition does *NOT* mean something like an attempt
to read past the end of file (that's what it means for stream or
internal files). Instead,

[216:38-40] An end-of-file condition occurs in the following cases: (1)
When an endfile record is encountered during the reading of a file
connected for sequential access..." [the other cases are for stream and
internal reads].

So reading *AFTER* the (possibly virtual) endfile record is not an
end-of-file condition as defined by the standard. It is just illegal.

My personal opinion is that an error condition more "naturally" reflects
the idea of the code being illegal. Thus I think that gfortran is more
in accord with the spirit of the standard here. But neither compiler can
be labelled as non-conforming, strictly speaking.

By the way, I'm not 100% certain, but I think I might recall that at
least CVF (and I would think therefore also ifort, but that part could
also be wrong) once had a switch to control this behavior - signalling
an error for closer adherence to the spirit of the standard, or
signalling and eof condition for compatibility with programs that
assumed the other behavior. So your claim of what ifort does might
depend on the specific version and switch settings. Or maybe I'm just
confusing this with some other issue where CVF switched to more
standard-conforming behavior, but provided a switch so that it didn't
break existing codes depending on nonstandard behavior.

For those who might bring up multi-file files, as in the previous
discussion of this issue, note that neither ifort nor gfortran support
any such thing (as far as I know).

Thanks Richard, I think we'll leave as is then. This is related to pr25139 in case you were wondering.

Best Regards,

Jerry
.

Relevant Pages

  • Re: Need interpretation
    ... > gfortran and ifort give different results with those two lines commented ... I'd think that a darn queer way for a compiler to behave, ... Note that the standard just ... In case you wonder, by the way, yes your file has an endfile record. ...
    (comp.lang.fortran)
  • Re: char * vs. const char *
    ... Your compiler probably has a way to turn down the warning level; ... The only 'switch' would be a cast. ...
    (comp.lang.c)
  • Re: struct point not identified by gcc
    ... [about sqrt findable without specific switch.] ... It is not about the compiler either. ... standard C library supplied on the OS contains sqrt, ... with the compiler hoping and praying that someone sent a ...
    (comp.lang.c)
  • Re: Is C99 the final C? (some suggestions)
    ... > that someone will try compile their stuff on an old compiler. ... > because the ANSI standard obsoleted them, and everyone picked up the ANSI ... fixed by using another language. ... >>are multiplying two expressions of the widest type supported by your ...
    (comp.lang.c)
  • Re: Statement on Schildt submitted to wikipedia today
    ... to working programmers and more with being "right all the time, ... so that compiler developers could be shed ... The major corporate interests were compiler developers, ... processors, committed to standard division semantics, and otherwise ...
    (comp.lang.c.moderated)