Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!csd4.csd.uwm.edu!uakari.primate.wisc.edu!indri!ames!pacbell!att!chinet!les
From: les@chinet.chi.il.us (Leslie Mikesell)
Newsgroups: comp.lang.c
Subject: Re: ReadKey like Function in C
Message-ID: <9315@chinet.chi.il.us>
Date: 21 Aug 89 01:23:08 GMT
References: <148@trigon.UUCP> <225800206@uxe.cso.uiuc.edu> <1677@crdgw1.crd.ge.com> <19095@mimsy.UUCP> <2855@ssc-vax.UUCP>
Reply-To: les@chinet.chi.il.us (Leslie Mikesell)
Organization: Chinet - Public Access Unix
Lines: 20

In article <2855@ssc-vax.UUCP> leea@ssc-vax.UUCP (Lee Carver) writes:

>>What does `kbhit()' mean when stdin is a socket?  How about in a VMS
>>batch job?

>>Before you settle on <X> as a standard across hundreds of systems, be sure
>><X> can well-defined everywhere.

>Yes, but kbhit() can be "well defined" for all streams.  kbhit()
>should return true if the next "getch()" (or read ( fd, buf, 1 ))
>will NOT block.  This means that the data must already be available
>to the OS, and simply awaits transfer to the application.

But what we really need is a way to determine *how many* characters
can be requested by a read() on an arbitrary stream (tty/file/pipe)
without blocking.  If you are going to ask for some new standard it
might as well be useful - moving data with 1 character read()'s is
not a good way to do things.

Les Mikesell