(j3.2006) paper J3/14-174 (again)
Robert Corbett
robert.corbett
Mon Jun 16 05:42:34 EDT 2014
I still do not understand the intent of paper J3/14-174.
The paper proposes not to have the next standard forbid
a standard-conforming program from connecting a single
file to more than one unit at a time. Is the intent of
the paper that the results of all I/O operations on
different units connected to the same file are
processor dependent?
Consider, for example, the program
PROGRAM MOUT
OPEN (10, FILE='MYFILE', FORM='UNFORMATTED', STATUS='REPLACE')
OPEN (11, FILE='MYFILE', FORM='UNFORMATTED', STATUS='OLD')
WRITE (10) 1, 2, 3, 4
WRITE (10) 5
WRITE (11) 6
WRITE (11) 7
REWIND (10)
CLOSE (11)
DO
READ (10, END=99999) I
PRINT *, I
END DO
99999 CLOSE (10)
END
When I compile and run this program using Oracle Solaris
Studio Fortran, I get the output
6
7
5
I see nothing in the standard that requires this result,
and I suspect that other implementations will produce
different results.
Consider the program
PROGRAM MINTTY
CHARACTER C
OPEN (10, FILE='/dev/tty')
OPEN (11, FILE='/dev/tty')
READ (10, '(A)') C
PRINT *, C
READ (11, '(A)') C
PRINT *, C
CLOSE(10)
CLOSE(11)
END
When I compile and run this program and give it the input
ab
cd
the program writes
a
c
If I change the values of the FILE= specifiers to be the
name of a regular file, the results for the same input
a
a
If I change the values of the FILE= specifiers to be the
name of a named pipe, the results depend on the size of the
input. If the data written to the named pipe from outside
the program consists of PIPE_BUF or fewer bytes, the second
READ statement hangs waiting for input until more data is
written to the named pipe. If the data consists of more
than PIPE_BUF bytes, the second READ statement treats the
PIPE_BUF + 1st character of the data as the first character
seen by unit 11.
Robert Corbett
More information about the J3
mailing list