------- Comment #13 from burnus at gcc dot gnu dot org 2010-03-11 11:08 ------- (In reply to comment #10) > I plan to commit the following as a compromise. We have had several PRs here > that contradict.
I am not sure whether the PRs really contradict as they just ask "do what the other compilers do", which is arguably not well defined but non-contradicting so far - the standard is (on purpose) not very explicit, unfortunately. (Fortunately, ifort, openf95, NAG f95 give the same result so far - and only for few special cases, gfortran does not.) > All of these involve missing EOR at the end of a file. Some want the EOF to > be interpreted as the EOR and some don't. As a follow-up patch I am wondering > if we should treat the missing EOR at EOF as an EOR with -std=legacy and > default to giving an EOF otherwise. I am extremely unhappy about different run-time behaviour depending on some compile-time flags as it causes differences, which are extremely difficult to pin point - both for the users and for us during bug reports. The common notion seems to be: If there is any character read before <eof>, that's a normal record and reading e.g. "(a80)" or "(100x)" or "(i20)" is allowed. If there is no character, not even a "\n", reading anything implies EOF. * * * Can this PR now be closed? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43320
