From: "Mark E." <snowball3 AT bigfoot DOT com>
To: djgpp-workers AT delorie DOT com
Date: Mon, 23 Jul 2001 23:19:41 -0400
MIME-Version: 1.0
Content-type: text/plain; charset=US-ASCII
Content-transfer-encoding: 7BIT
Subject: Re: extended keys support
Message-ID: <3B5CB10D.7118.2DBD51@localhost>
X-mailer: Pegasus Mail for Win32 (v3.12c)
Reply-To: djgpp-workers AT delorie DOT com

> *************** __libc_termios_read_raw_tty (int handle,
> *** 340,364 ****
> --- 480,523 ----
>       __libc_termios_clear_queue ();
>   
>     /* block until getting inputs */
> !   while (enh_key_string == 0 && (sense = __direct_keysense()) == SENSE_NO_KEY)
>       __dpmi_yield ();
>   
>     while (--n >= 0)
>       {
>         /* exhaust inputs ? */
> !       if (enh_key_string == 0 && sense == SENSE_NO_KEY)
>   	break;
>   

This portion won't work if the extended key has no encoded value. Reworked as 
follows:
  while (enh_key_string == 0 && __direct_keysense() == SENSE_NO_KEY)
    __dpmi_yield ();

  while (--n >= 0)
    {
      sense = __direct_keysense();

      /* exhaust inputs ? */
      if (enh_key_string == 0 && sense == SENSE_NO_KEY)
	break;

and the sense assignment at the bottom of the block is deleted.

I'd like to split the code for reading and writing into their own files since 
code for doing these things will be increasing with the functionality being 
added. However, I think some of the code can be removed.

_libc_termios_read has code to call raw and cooked versions of reading from 
the console. If the handle is a file, it then reads from the file into the 
buffer. This seems like a waste since returning 0 will cause read() to do the 
right thing.  Same idea with __libc_termios_write: dump the extra file 
writing code and return 0.

Mark