http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30162
--- Comment #50 from Janne Blomqvist <jb at gcc dot gnu.org> 2013-02-19 10:59:30 UTC --- (In reply to comment #47) > Am 18.02.2013 21:16, schrieb jb at gcc dot gnu.org: > >> Look at this piece of code: > >> > > >> > /* Seek to the head and overwrite the bogus length with the real > >> > length. */ > >> > > >> > if (unlikely (sseek (dtp->u.p.current_unit->s, - m - 2 * record_marker, > >> > SEEK_CUR) < 0)) > >> > goto io_error; > >> > > >> >This works if it happens within a buffer, but you cannot rely on that. > >> > > >> >I would therefore suggest to resolve this PR by issuing a well-defined > >> >error if we encounter a pipe on opening. > >> > > >> >I'll prepare a patch. > > As I explained in comment #23, this is already handled. When opening a > > file, we > > stat() the fd, and use the buffered I/O functions only if it's a regular > > file, > > otherwise the unbuffered raw I/O functions are used. > > This is part of the precipitate, not part of the solution ;-) > > For unformatted sequential, we first write a dummy record marker, write > the data and the final record marker, then seek to the first marker > and re-write that. Of course, this fails for an unbuffered fifo. > > If we want this to work, we should make sure we always use > _buffered_ I/O for unformatted sequential, setting a maximum > record length on open that we can handle with our buffer. The buffered I/O functions generally assume that the underlying fd is a regular file; if you break that be prepared to handle a bunch of subtle fallout. I tried playing that whack-a-mole game a few years ago until I got tired of it and restricted buffered I/O to regular files. Wrt to pipes, one regression we had (I don't remember the PR number) was a deadlock due to the buffering. E.g. one process writes "hello" to the pipe, the other one answers "hello, neighbor". The write part could be handled by executing the FLUSH statement, but I recall there was some problem on the read side as well, something to do with read() hanging due to there not being any data available in the pipe when it tried to fill the buffer. Anyway, I don't think this is something libgfortran can, or should, try to fix. If the user tries to do something requiring seeking on a special file that doesn't support seeking, they get what they deserve. The real bug here is that we try to seek even though the Fortran semantics don't require it (mind that the complaint in comment #22 which reopened this PR refers to formatted I/O).
