From: cgf AT cygnus DOT com (Christopher Faylor) Subject: Re: B20 patch: CR handling in fhandler_console 3 Dec 1998 05:27:04 -0800 Message-ID: <19981203081701.A9575.cygnus.cygwin32.developers@cygnus.com> References: <3665D672 DOT A1722461 DOT cygnus DOT cygwin32 DOT developers AT cityweb DOT de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii To: Corinna Vinschen , DJ Delorie , cygwin32-developers AT cygnus DOT com On Thu, Dec 03, 1998 at 12:26:02PM +0100, Corinna Vinschen wrote: >- The next if clause after the mentioned one is the code, which > kills CR if LF follows. So, in this case, the mentioned one is > unnecessary. When copied_chars > 1! Or did you want to index before the beginning of the buf array. >- I have a code example (from an implementation of att-robots): > > struct termio sav_tio, tio; > > tcgetattr (0, &sav_tio); > tio = sav_tio; > tio.c_lflag &= ~(ECHO | ICANON); > tio.c_cc[VMIN] = 1; > tio.c_cc[VTIME] = 0; > tcsetattr(0, TCSADRAIN, &tio); > > ... player plays its game ... > ... all input is done by read(0, ... > > tcsetattr(0, TCSADRAIN, &sav_tio); > > "Hit [RETURN] to continue" > > getchar(); > > The above getchar() fails, if the player presses RETURN without > pressing any other key before! This behaviour is not only incorrect, > but also doesn't happen in CYGWIN=tty mode. > An STRACE output shows, that ReadFile only returns CR, which > is discarded by the mentioned code piece. If the player presses > e.g. SPACE RETURN, you can see: 0x20, 0x0d as input, which is > _not_ cooked by the code in read1. I think, this is also not, what > the code should be for. > Maybe, this can be backtracked to an error in Windows console handling, > but IMHO the console code shouldn't support this misbehaviour. > >These are _not_ arguments for the correctness of the patch. But I'm >testing it and anything works as before, moreover, the above code >works, too. So, the patch could be a temporary workaround. > >Eventually, the next if ("Perform a similar test on a buffer with > 1 >character. If it ends in \r\n then fix it up") should be deleted, too, >because this conversions have to be done by fhandler_console::read(). >This method contains the conversions, which are configured by stty modes >(e.g. ICRNL, IUCLC). Cooking is the business of configurable code. The >discussed hardcoded cooking code in read1() could break the stty settings. >What, if ICRNL is unset by intention? Ok. I understand your point, but removing the code in your original mail is not the answer. -chris -- cgf AT cygnus DOT com http://www.cygnus.com/