From: pfitz AT pratique DOT fr (Tony FITZPATRICK) Subject: RE: "info.exe" finally working on W95 13 Mar 1997 18:04:21 -0800 Approved: cygnus DOT gnu-win32 AT cygnus DOT com Distribution: cygnus Message-ID: <199703132130.WAA04737.cygnus.gnu-win32@prat.iway.fr> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Sender: pfitz AT mail DOT pratique DOT fr (Unverified) X-Mailer: Windows Eudora Light Version 1.5.2 Original-To: Sergey Okhapkin Original-Cc: "gnu-win32 AT cygnus DOT com" Original-Sender: owner-gnu-win32 AT cygnus DOT com At 11:56 13/03/97 +0300, you wrote: >> >> #include >> #define O_NDELAY _FNDELAY >> extern int ndelay_set; >> > >It's better to use c_cc[VMIN] and c_cc[VTIME] fields of termios structure >for this. Would You like to correct Your patch according to this note? > Thanks for the response and I agree with you that "fhandler.cc" should also take into account the case were VMIN and VTIME are both zero as it has the same effect as O_NDELAY. However, if I understand you correctly, I still have a problem with O_NDELAY. I could interpret O_NELAY in "fcntl" and set VMIN and VTIME to zero for "fhandler" to interpret later but I would have to save the current values of VMIN and VTIME to restore them the next time "fcntl" is called without the O_NDELAY flag and it is this that worries me. "info.exe" is an example of a program which uses both VMIN/VTIME and O_NDELAY in the same program. It appears to use O_NDELAY to temporarily override the VMIN/VTIME settings. Using VMIN/VTIME to implement O_NDELAY would work in this case but it would not in the opposite case. VMIN=a VTIME=b fcntl (tty, F_SETFL, (flags | O_NDELAY)); ... ttybuff.c_cc[VMIN] = 1; ttybuff.c_cc[VTIME] = 0; tcsetattr (tty, TCSANOW, &ttybuff); ... fcntl (tty, F_SETFL, flags); VMIN=a VTIME=b and not VMIN=1 VTIME=0 as they should be! I accept that this kind of programming is improbable but anything is possible. I haven't found any documentation that says O_NDELAY takes priority over VMIN/VTIME either. O_NDELAY and VMIN/VTIME work on entirely different structures and creating this kind of interaction between them does not seem to me to be a good idea, it is also not necessary. I have to admit however that I don't understand the difference between the attributes of a "file descriptor", a "console" and a "terminal" and why there are two ways to do the same thing, still, nobodys perfect. Tony - For help on using this list, send a message to "gnu-win32-request AT cygnus DOT com" with one line of text: "help".