http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30162
--- Comment #29 from Janne Blomqvist <jb at gcc dot gnu.org> 2012-11-25 15:08:24 UTC --- (In reply to comment #28) > (In reply to comment #27) > > (In reply to comment #26) > > > Is this caused by > > > > > > http://gcc.gnu.org/viewcvs?view=revision&revision=180701 > > > > > > ? > > > > > > Maybe we need to remember if we have a special file after all, or just > > > ignore > > > the error on the truncate. > > > > IMHO the correct fix is to not seek and/or truncate the file unless the > > Fortran > > semantics require it; that way libgfortran does not need to care whether the > > file is special or not. As explained in #c23, special files are special in > > different ways (also different on different OS'es), and trying to enumerate > > all > > the ways in which they are special is bound to fail. > > > > I think Tobias comment #c24 pinpoints the place which needs to be fixed, but > > unfortunately I haven't had time to look into it. > > Well, we need to make sure that the (very basic) program > > program main > character*10 x > open(10,file="foo.dat") > write (10,'(A)') '1111' > write (10,'(A)') '2222' > close (10) > open(10,file="foo.dat") > write (10,'(A)') '3333' > close (10) > open(10,file="foo.dat") > 100 continue > read (10,'(A)',end=200) x > write (*,'(A)') x > goto 100 > 200 continue > close(10,status="delete") > end > > continues to work as expected: That probably means truncating on > close and rewind. I'm not sure about truncation being necessary here, actually. Where we do need to truncate is 1) Following a write in access='sequential' mode, when we are not at the end of the file (that is, we have opened an existing file and are at the beginning, we have previously used rewind/backspace or such). This might also apply to formatted writes in access='stream' mode, need to check the standard. 2) Executing an ENDFILE statement. 3) Opening a file with status='replace' (actually, probably not, as a sensible implementation would be to open() with O_TRUNC instead of a separate ftruncate() call following open(), and while I'm too lazy to look it up right now I'm quite sure this is exactly what we already do) I think the current code goes wrong with pipes because as they are reported to be of size 0, it is undefined whether we're at the beginning, middle, or end of the file, and hence we have made some arbitrary choice, and hit_eof() think's we're not at the end, and tries to truncate. Perhaps we need something more sophisticated such as some need_to_truncate_after_next_write flag which is set and tested at appropriate places..
