This is the mail archive of the 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] PR32784 CONIN$, CONOUT$, and CONERR$ for Cygwin and mingw

Danny Smith wrote:

  Pardon me Danny, I'm piggybacking on your reply here but it's mostly
directed at Jerry.

> On Sun, Jun 14, 2009 at 1:30 PM, Jerry DeLisle<> wrote:
>> Jerry DeLisle wrote:
>>> The attached patch provides mapping the special file names to standard IO.
>>>  This is an extension requested quite a ways back.
>>> Applied and tested / regression tested on Cygwin running on WinNT
>>> workstation. I do not have a working mingw set-up and would much appreciate
>>> someone building and testing for that system.
>>> OK for trunk if so tested and passes?
>> Here is a simple test case i have used.  Redirection on the output apears to
>> work as well.
>>      character(25) :: astring
>>      open(unit=29,file='CONOUT$')
>>      write(29,100)
>> 100   format('Hello, world!')
>>      open(unit=39,file='CONERR$')
>>      write(39,200)
>> 200   format('This goes to conerr$!')
>>      open(unit=49,file='CONIN$')
>>      read(49,'(a)') astring
>>      write(29,'(a)') astring
>>      end
> The testcase fails on mingw32. This is the output, when run from DOS cmd:
> Hello, world!
> This goes to conerr$!
> The program then hangs until I press <Enter> key. 

  That would be it waiting for input on CONIN$, wouldn't it?

> The last output to CONOUT is lost.

> Similar problems occur if I redirect stdout or stderr output.
> If redirect stdin through a pipe (eg when testing the program from a
> text editor) I get:
> Hello, world!
> This goes to conerr$!
> At line 9 of file conout.f90 (unit = 49, file = 'CONIN$')
> Fortran runtime error: Bad file descriptor

  Jerry, I see you describe it as an extension, but I don't understand what
this patch is meant to do.  CONIN$/CONOUT$/CONERR$ are not supposed to be the
same things as stdin/out/err, particularly when redirection is in effect; in
Win32 terms, they mean "Get me a real console, I want to talk to it no matter
what".  For instance, if I run this cygwin C testcase in a DOS console:

$ cat tc3.c

#include <stdio.h>
#include <string.h>
#include <stdlib.h>
#include <fcntl.h>

#define STRING1  "String 1 to CONOUT!\n"

int main ()
  int fd1;
  fd1 = open ("/dev/conout", O_WRONLY);
  write (fd1, STRING1, strlen (STRING1));
  close (fd1);
  printf ("Hello world!\n");
  return 0;

admin@ubik /tmp/console
$ gcc-4 -g -O0 tc3.c -o tc3

admin@ubik /tmp/console
$ ./tc3.exe
String 1 to CONOUT!
Hello world!

admin@ubik /tmp/console
$ ./tc3.exe > foo
String 1 to CONOUT!

admin@ubik /tmp/console
$ cat foo
Hello world!

admin@ubik /tmp/console

... you see that the whole point of CONOUT$ is that it doesn't get redirected
even when stdout does.  This is even more dramatically demonstrated if I
launch a cygwin gui console like rxvt, which doesn't have an actual windows
console underlying it; the CONOUT$ output goes to the original DOS console
from which I launched rxvt.  So, this is a somewhat strange thing for the
runtime to want to do; shouldn't it be at least under the control of some
option or flag?


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