[Bug libfortran/30162] [4.7/4.8 Regression] I/O with named pipes does not work on Darwin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30162 --- Comment #48 from tkoenig at netcologne dot de 2013-02-18 21:29:22 UTC --- Am 18.02.2013 20:15, schrieb dominiq at lps dot ens.fr: > Are you suggesting to "fix" the non working named pipes on Darwin by removing > them everywhere? Actually, the error happens everywhere, I could reproduce the error with unformatted sequential on my Linux box. > If yes, isn't it a little bit too radical? Formatted sequential, unformatted stream and formatted stream would continue to work. As BACKSPACE most certainly will not work on a pipe, I don't see the advantage of using unformatted sequential.
[Bug libfortran/30162] [4.7/4.8 Regression] I/O with named pipes does not work on Darwin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30162 --- Comment #47 from tkoenig at netcologne dot de 2013-02-18 21:24:31 UTC --- 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.
[Bug libfortran/30162] [4.7/4.8 Regression] I/O with named pipes does not work on Darwin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30162 --- Comment #46 from Janne Blomqvist 2013-02-18 20:16:28 UTC --- (In reply to comment #44) > If unformatted sequential ever worked, it was by chance. > > 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.
[Bug libfortran/30162] [4.7/4.8 Regression] I/O with named pipes does not work on Darwin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30162 --- Comment #45 from Dominique d'Humieres 2013-02-18 19:15:43 UTC --- > ... > I would therefore suggest to resolve this PR by issuing a well-defined > error if we encounter a pipe on opening. Are you suggesting to "fix" the non working named pipes on Darwin by removing them everywhere? If yes, isn't it a little bit too radical? If there are pieces of code working only by chance, would not it be better to fix them?
[Bug libfortran/30162] [4.7/4.8 Regression] I/O with named pipes does not work on Darwin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30162 --- Comment #44 from Thomas Koenig 2013-02-18 18:44:02 UTC --- If unformatted sequential ever worked, it was by chance. 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.
[Bug libfortran/30162] [4.7/4.8 Regression] I/O with named pipes does not work on Darwin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30162
--- Comment #43 from Dominique d'Humieres
2013-02-17 20:10:52 UTC ---
I finally had a look at this PR.
First the test on comment #41 works on x86_64-apple-darwin10 r196109:
macbook] f90/bug% mkfifo pipe
[macbook] f90/bug% read_f &
[1] 6998
[macbook] f90/bug% write_f
Hello, world!
[macbook] f90/bug%
[1]Done read_f
I have done the following changes to the original test:
[macbook] f90/bug% cat pr30162_1_db.f
integer status
integer i
open(unit=20,file='np',action='write',
& form='unformatted',iostat=status);
print*,'status for write from open is ',status
do i = 1,5
print *, "write ", i
write(20)i
end do
end
[macbook] f90/bug% cat pr30162_2_db.f
integer status
integer i
integer val
open(unit=21,file='np',action='read',
& form='unformatted',iostat=status);
print*,'status for read from open is ',status
do i = 1,5
read(21)val
print*,val
end do
end
and I got
[macbook] f90/bug% write_f
status for write from open is0
write1
At line 8 of file pr30162_1_db.f (unit = 20, file = 'np')
Fortran runtime error: Illegal seek
status for read from open is0
At line 8 of file pr30162_2_db.f (unit = 21, file = 'np')
Fortran runtime error: I/O past end of record on unformatted file
[macbook] f90/bug%
[1]Exit 2read_f
Then I have applied the following patch (based on r194679):
--- ../_clean/libgfortran/io/unix.c2013-01-14 19:25:10.0 +0100
+++ libgfortran/io/unix.c2013-02-17 20:23:43.0 +0100
@@ -336,7 +336,14 @@ raw_write (unix_stream * s, const void *
static gfc_offset
raw_seek (unix_stream * s, gfc_offset offset, int whence)
{
- return lseek (s->fd, offset, whence);
+ gfc_offset x;
+ x = lseek (s->fd, offset, whence);
+ /* Non-seekable files should always be assumed to be at
+ current position. */
+ if (x == -1 && errno == ESPIPE)
+x = 0;
+ return x;
+ /* return lseek (s->fd, offset, whence); */
}
static gfc_offset
and now I get
[macbook] f90/bug% write_f
status for write from open is0
write1
write2
write3
write4
write5
status for read from open is0
At line 8 of file pr30162_2_db.f (unit = 21, file = 'np')
Fortran runtime error: I/O past end of record on unformatted file
[macbook] f90/bug%
[1]Exit 2read_f
So the write seems now OK. For the read, dtrace gives
fstat64(0x3, 0x7FFF5FBFD580, 0x50) = 0 0
fstat64(0x3, 0x7FFF5FBFD5C0, 0x0) = 0 0
lseek(0x3, 0x0, 0x1) = -1 Err#29
write(0x1, " status for read from open is0\n\0", 0x2B) = 43
0
read(0x3, "\0", 0x4) = 4 0
read(0x3, "\0", 0x0) = 0 0
lseek(0x3, 0x4, 0x1) = -1 Err#29
write(0x2, "At line 8 of file pr30162_2_db.f (unit = 21, file = 'np')\n\0",
0x3A) = 58 0
write(0x2, "Fortran runtime error: \0", 0x17) = 23 0
write(0x2, "I/O past end of record on unformatted file\0", 0x2A) = 42 0
write(0x2, "\n\0", 0x1) = 1 0
close(0x3) = 0 0
i.e., 2 errors #29 on lseek. I did not find out how this is connected to the
error "I/O past end of record on unformatted file".
