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 onas 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.