https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61632
--- Comment #19 from Jerry DeLisle <jvdelisle at gcc dot gnu.org> --- (In reply to Dominique d'Humieres from comment #15) > > Its sort of like Steve said earlier. The coder is choosing to ignore an > > error condition so anything gfortran does is valid. In this case the > > output got writen to buffer before the error occurred. You are bypassing > > all of the normal error handling when you do this. The buffer got flushed. > > > > Its not worth the time to change any of it really. > > > > The program should exit, its invalid. I simply mean the Fortran code in the test case is invalid Fortran. Fix the Fortran code. Now suppose the error is a disk full. Should the user just ignore that and keep trying to write to the disk? > > Well, I disagree with this interpretation: I did not find anywhere in the > standard that the variable set by iostat has to be used. In addition, the > following code should be valid upon Steve's rules and still prints 'YYY' ---snip--- Regarding the "YYY". Why not print it? the error occurs after it is written. If you do not "catch" the error, the runtime leaves early, out of all the various processing loops, and exits the program. Whereas when the error is caught, we continue execution in the library where we detected the error and happily proceeds. The transfer is directed by the format string, it went as far as it could go. (As opposed to list directed I/O) > > IMO this PR boils down to the fact that the I/O processing is not reset to a > clean state after an error is handled with ERR, IOSTAT, ... , as it should. The standard uses the term indeterminate. You prefer it to be determined. OK Person A wants the file buffers flushed, the file closed, and reopened with status="append". Person B wants to grab the file position, clear the buffers, rewind the file, read it back in, parse it for bad content, and signal an alarm on the console. The user can do these things if they want to. > > Along this line, I have found that 'parse_format' is called only once even > if 'ss' is called twice. This is by design. The string is parsed once for efficiency and reused for performance purposes. Its a choice we made some time ago. The runtime checks the string for a match to previously parsed strings. Saves a lot of run time. The parsed (tokenized) format is saved elsewhere and reused.
