------- Comment #4 from burnus at gcc dot gnu dot org 2006-12-08 17:17 ------- (In reply to comment #3) > In the case of (un)formatted= there may be a file or device that would > not support unformatted I/O due to internal restrictions on the data set, for > example ASCII only. In that case unformatted would just not work. > I am not sure whether this is just a legacy feature or whether the standard > makers included this for completeness. Regardless, it doe not seem to be very > useful.
Well, maybe one can see easily on some systems whether a given file is (un)formatted or not. In terms of values reported: gfortran/g95 say: YES if it can be opened, regardless whether it makes sense or not. -- this avoids false negatives and the file can indeed be opened that way. ifort/sunf95/f95 say: UNKNOWN or - if it is opened only YES to the type where they know that it is the right one. -- This is the (over)careful way to report nothing which could be wrong. I wonder whether it would make sense keep the current implementation for non-connected files and to return UNFORMATTED="NO" for a file, which has been opened as UNFORMATTED and vice versa. I think the number of (non-empty) files, which can be opened both as UNFORMATTED and as FORMATTED is very limited - and if it is opened, accessing it with the wrong method is also not such a good idea. This would make UNFORMATTED/FORMATTED more useful for opened files and be more compatible with legacy code. But this is of cause an implementation choice. (FORM is indeed the better choice and the original bug reported told me in a private mail that he is indeed now using the FORM specifier.) > The fact that this has come up again indicates that maybe we need some > documentation in the gfortran manual to explain this to users. Intuitively > they want to grab the wrong specifier to find out if a file was opened for > formatted or unformatted I/O. I think this is indeed a good idea. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30114
