[patch, libfortran] PR44931 For INPUT_UNIT, INQUIRE NAME= should not return "stdin"
Jerry DeLisle
jvdelisle@verizon.net
Sun Jul 25 15:31:00 GMT 2010
On 07/25/2010 02:00 AM, Tobias Burnus wrote:
> Dear Jerry, Dave, and Kai,
>
> Dave and Kai: I have CCed you as I have a question regarding MinGW/Cygwin.
>
> Jerry DeLisle wrote:
>> The attach patch uses ttyname to return the device file name for
>> inquire by unit.
>> Regression tested on x86-64.
>>
>> Test case attached, but the results are system dependent so I will not
>> add it to the testsuite.
>
> Kai, Dave: The idea is that INQUIRE returns for stdin, stdout, and
> stderr a "filename", which can be used to '(re)open' ([re]associate) a
> Fortran I/O unit number with those standard I/O "streams". (Non
> normative note in the standard: "the value [for NAME=] returned [by
> "INQUIRE(UNIT=...,NAME=...)"] shall be suitable for use as the value of
> the file-name-expr in the FILE= specifier in an OPEN statement.")
>
> Under Unix, ttynam should roughly do this, but I fear it might not work
> under Windows - in particular under MinGW(.org,64). Or does it?
ttynam is supported under Cygwin according to their documentation. I will test it.
Regarding mingw-32/64 I will defer to Kai, but it looks like they do from googling.
>
> Would it be an option to use conout$, conin$ and conerr$ for those? I
> think on MinGW, libgfortran (io/unix.c) uses them directly (well conerr$
> = conout$) while on cygwin those are mapped to /dev/con{in,out,err}. At
> least for MinGW this seems to be required as Windows does not seem to
> have a tty concept. For Cygwin the Unix approach should work.
>
>> OK for trunk?
>
> I think you need to guard the use of ttyname by
>
> #ifdef HAVE_TTYNAME
> ...
> #else
> ...
> #endif
>
> Besides, I wonder whether using "" as string is better than using the
> default std{in,out,err} in case ttyname fails. (This happens for
> instance if the standard I/O redirected to a file or pipe.)
>
> Otherwise, the patch looks fine to me.
I have guarded it with HAVE_TTYNAME and if not defined we fall back to current
gfortran behavior which almost everyone is happy with. I have tested that it
works. To me this is the safest way to go initially with this.
OK to commit?
Jerry
More information about the Fortran
mailing list