[Bug libfortran/30162] [4.7/4.8 Regression] I/O with named pipes does not work

[jb at gcc dot gnu.org]

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..