I have also tried to use a named pipe created with mkfifo and this still happens.
Say I use matlab to make some data:
[plain]>> fid = fopen('test.bin','w'); >> fwrite(fid,double(pi),'double'); >> fclose(fid);[/plain]
then I try the following test program:
[fortran]program tester use iso_fortran_env implicit none doubleprecision :: pi integer :: error close(input_unit) open(unit=input_unit,access='stream',form='unformatted',iostat=error) write(output_unit,*) error read(input_unit,iostat=error) pi write(output_unit,*) error write(output_unit,*) iostat_end write(output_unit,*) iostat_eor write(output_unit,*), pi end program [/fortran]
Also, please note, the original source code douse not have an extra 'd' in the doubleprecision declaration. This appears to be a bug with the source highlighter.
[bash]ifort -g -warn all -check all -traceback -o tester tester.f90[/bash]
Using a pipe I get this:
[bash]$ cat test.bin | ./tester 0 38 -1 -2 1.117351266127586E-315 [/bash]
Using redirection i get this:
[bash]$ ./tester < src/matlab/roughness/test.bin 0 0 -1 -2 3.14159265358979[/bash]
Is this because there are no longer record indicators so when I close then reopen stdin as stream access the program loses track of where it is in the stream?
If I try this technique with sequential access I don't encounter this problem. (Note, you need to write binary data with fortran so that it includes the sequential access record indicators which are stripped off for stream access.)
The OPEN for stream I/O on pipe should work, however user program REWIND or SEEK should report error/warning (or at least be consistent with the FORTRAN standards committee position regarding this).
Perhapse a mode on the open can be used to indicate behavior for meaningless statements (or specify meaning of questionable statements).
Should REWIND on CON prompt the user to retype their input?
Should SEEK to 50 bytes from end of file on CON prompt the user to skip over the blah, blah, blah and type the last 50 bytes of their input.
The "processore dependent" behavior does not specifically mention file positioning behavior, except for the POS= specifier. But, note 9.3 states that the set of allowed actions on any external file are processor dependent, so just about any behavior is allowable within the standards.
IMHO, it is OK for any sort of explicit seek (REWIND or POS=) on a non-seekable file to fail. Standard I/O could be conditionally non-seekable, depending if it is a "tty" or a file.
Ideally, there should be a POSITIONABLE=
Quetion: Should an explicit REWIND on a non-seekable file that is already at the initial position be an error? Maybe it should just depend on the underlying OS handling of seek. If it is an error, then REWIND with IOSTAT on a freshly opened unit could be used to check postionability.
With regards to my "reopen" suggestion, it is already supported. If OPEN defines a file and unit already connected, only the "changeable modes" may be modified:
"A connection for formatted input/output has several changeable modes: these are the blank interpretation mode (10.8.6), delimiter mode (10.10.4, 10.11.4.2), sign mode (10.8.4), decimal edit mode (10.8.8), I/O rounding mode (10.7.2.3.7), pad mode (126.96.36.199.3), and scale factor (10.8.5). A connection for unformatted input/output has no changeable modes."
So, my proposal is to extend the set of changeable modes, at least for a file that is connected but has not yet transferred anything.