Path: utzoo!attcan!uunet!ginosko!aplcen!haven!adm!smoke!gwyn
From: gwyn@smoke.BRL.MIL (Doug Gwyn)
Newsgroups: comp.lang.c
Subject: Re: ReadKey like Function in C
Message-ID: <10746@smoke.BRL.MIL>
Date: 16 Aug 89 04:20:09 GMT
References: <148@trigon.UUCP> <225800206@uxe.cso.uiuc.edu> <1677@crdgw1.crd.ge.com> <19095@mimsy.UUCP>
Reply-To: gwyn@brl.arpa (Doug Gwyn)
Organization: Ballistic Research Lab (BRL), APG, MD.
Lines: 27

In article <19095@mimsy.UUCP> chris@mimsy.UUCP (Chris Torek) writes:
>What does `kbhit()' mean when stdin is a socket?  How about in a VMS
>batch job?
>What does getch() do at end of file?
>Before you settle on  as a standard across hundreds of systems, be sure
> can well-defined everywhere.

Although I agree with the sentiment, especially since I work in an
environment where it is not always clear what is meant by a "terminal",
but that's not a fatal objection.  The C Standard already allows
implementations to have some sort of notion of "terminal" and to do
certain operations slightly differently when a "terminal" is involved.
So far, this seems to be limited to whether or not output is fully or
just line buffered, which is a relatively unimportant matter for most
applications programs.  I personally prefer to explicitly fflush()
output when I want to be sure that it's seen before the program
proceeds.

Terminal input is a more difficult matter to deal with than output
buffering, because of the necessity to deal with mode switches (from
input cnanonicalizing to non-canonicalizing) in many environments.
The reason input canonicalization is done is of course to allow humans
to correct typical typing errors before their input is received by
applications; otherwise every application would have to take care of
it, which is obviously poor software design.

kbhit() and getch() are a poor model for such an environment.