Allow stream I/O on pre-attached stdin and stdout

[urbanjost]

The ability to read a stream from stdin, and to write a stream to stdout would be very useful to make filter programs especially so programs can be used in pipes with binary data.

A primary use of stream I/O is for creating programs that can be used in pipes on systems that support it. There is no standard way to reopen the preattached files connected to stdin and stdout as streams to support generating such applications. Non-advancing I/O does not solve the problem primarily because of there being a limit on line length and for other well-documented reasons.

Calling the C routines via the ISO_C_BINDING interface is the work-around I have seen used the most. If possible, an OPEN on the pre-attached files that allowed changing them to STREAM I/O and optionally binary seems like it would be the nicest syntax. Although far less preferred by myself even new intrinsics like GETC() and PUTC() that mirrored the C functions of the same name would be better than the current state. Note that in some programming environments you can do an INQUIRE() on the units and close and reopen them, but not on others. And there is the complication that you can usually only do that for the units defined by

use, intrinsic :: iso_fortran_env, only : stdin=>input_unit, stdout=>output_unit, stderr=>error_unit

and not necessarily the ones representing by "*". Not having this as a standard capability greatly limits the construction of filters using Fortran.

[sblionel]

Quoting 12.5.1p4 (emphasis mine)

In a READ statement, an io-unit that is an asterisk identifies an external unit that is preconnected for sequential formatted input on image 1 in the initial team only (12.6.4.3). This unit is also identified by the value of the named constant INPUT_UNIT of the intrinsic module ISO_FORTRAN_ENV (16.10.2.13). In a WRITE statement, an io-unit that is an asterisk identifies an external unit that is preconnected for sequential formatted output. This unit is also identified by the value of the named constant OUTPUT_UNIT of the intrinsic module ISO_FORTRAN_ENV (16.10.2.22).

That said, I agree it would be useful to be able to use the preconnected units for unformatted stream I/O. I think the simplest approach would be to require that INQUIRE() return a filespec that can be used in an OPEN for the preconnected units.

[urbanjost]

That would be great; especially since some programming environments do already return a usable name from an INQUIRE that can be used that way; but others return a string like "stdin" and "stdout" that does not work as a name on OPEN() or a blank name. So I have seen that model be workable in some current environments.

On January 11, 2020 at 10:02 AM Steve Lionel notifications@github.com wrote:

Quoting 12.5.1p4 (emphasis mine)

    > > 

    In a READ statement, an io-unit that is an asterisk identifies an external unit that is preconnected for sequential formatted input on image 1 in the initial team only (12.6.4.3). This unit is also identified by the value of the named constant INPUT_UNIT of the intrinsic module ISO_FORTRAN_ENV (16.10.2.13). In a WRITE statement, an io-unit that is an asterisk identifies an external unit that is preconnected for sequential formatted output. This unit is also identified by the value of the named constant OUTPUT_UNIT of the intrinsic module ISO_FORTRAN_ENV (16.10.2.22).

> 

That said, I agree it would be useful to be able to use the preconnected units for unformatted stream I/O. I think the simplest approach would be to require that INQUIRE() return a filespec that can be used in an OPEN for the preconnected units.

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub https://github.com/j3-fortran/fortran_proposals/issues/136?email_source=notifications&email_token=AHDWN3NNSK2VNN7F5XGK763Q5HNQ3A5CNFSM4KFLUBR2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEIWDX3Y#issuecomment-573324271 , or unsubscribe https://github.com/notifications/unsubscribe-auth/AHDWN3JSBLZSKMUTIYAPJH3Q5HNQ3ANCNFSM4KFLUBRQ .

[sblionel]

I would argue that implementations that do not return a usable name for INQUIRE(NAME=) are not following the standard, which says: "The value assigned shall be suitable for use as the value of the file-name-expr in the FILE= specifier in an OPEN statement."

But there is an escape that if it is deemed that the file doesn't have a name, then the value of NAME= becomes undefined (and presumably NAMED= would return .FALSE.)

It may be that reopening the file wouldn't work anyway...

I'm struggling to come up with a "Fortranic" (love that term) way of expressing the notion here. Fortran does have "changeable modes", but ACCESS and FORM aren't among them.

[urbanjost]

Even the syntax is hard to make "Fortranic" (I like that). Even something like a specifier on the READ or WRITE (which is allowed for other properties) or instead of for a unit specifier might be good syntactically, but I wonder about implementing something that way, as it would imply that a single file could be written to with different attributes in the same program (that is, if the program had both WRITE(,...) and WRITE(,...) statements would that be feasible?). Even deciding if ** meant UNFORMATTED STREAM or FORMATTED STREAM takes thought. And yet this is a common and useful feature of other languages. It is very limiting to not be able to create Fortran filter programs that reliably can read a binary stream, as just one example. I find myself precariously using non-advancing I/O or calls to C getc(c) and putc(); which is very limiting compared to a fully supported Fortran I/O interface.

On January 12, 2020 at 2:46 PM Steve Lionel notifications@github.com wrote:

I would argue that implementations that do not return a usable name for INQUIRE(NAME=) are not following the standard, which says: "The value assigned shall be suitable for use as the value of the file-name-expr in the FILE= specifier in an OPEN statement."

But there is an escape that if it is deemed that the file doesn't have a name, then the value of NAME= becomes undefined (and presumably NAMED= would return .FALSE.)

It may be that reopening the file wouldn't work anyway...

I'm struggling to come up with a "Fortranic" (love that term) way of expressing the notion here. Fortran does have "changeable modes", but ACCESS and FORM aren't among them.

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub https://github.com/j3-fortran/fortran_proposals/issues/136?email_source=notifications&email_token=AHDWN3NRPPTOXPJNE3LHU2DQ5NXQDA5CNFSM4KFLUBR2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEIXCO6Q#issuecomment-573450106 , or unsubscribe https://github.com/notifications/unsubscribe-auth/AHDWN3O6DLLHACLP5APWAYDQ5NXQDANCNFSM4KFLUBRQ .