This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [patch, libfortran] PR44931 For INPUT_UNIT, INQUIRE NAME= should not return "stdin"


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]