Xref: utzoo comp.lang.c:36711 comp.std.c:4415
Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!uakari.primate.wisc.edu!zaphod.mps.ohio-state.edu!lavaca.uh.edu!menudo.uh.edu!sugar!ficc!peter
From: peter@ficc.ferranti.com (Peter da Silva)
Newsgroups: comp.lang.c,comp.std.c
Subject: Re: Keyboard support in C (was Re: making characters disappear)
Message-ID: <_JT93L5@xds13.ferranti.com>
Date: 1 Mar 91 21:46:27 GMT
References: <1991Feb23.014700.16507@ico.isc.com> <1991Feb19.015727.2223@to.rushpc> <1991Feb23.170142.538@ux1.cso.uiuc.edu> <15302@smoke.brl.mil> <14542@ganymede.inmos.co.uk>
Reply-To: peter@ficc.ferranti.com (Peter da Silva)
Organization: Xenix Support, FICC
Lines: 24

In article <14542@ganymede.inmos.co.uk> conor@inmos.co.uk (Conor O'Neill) writes:
> The function ("inkey", or whatever it might be called) could simply
> return an error code if it could not be supported.

Perhaps a better model would be something like:

	open_keyboard()	/* tell the library you're gonna do something
			 * with the keyboard, return YES/FAILURE */
	set_mode(ECHO|NOECHO|LINE|CHARACTER)	/* Set echo/erase/etc mode */
	check_key()	/* return YES/NO/FAILURE */
	wait_key(t)	/* wait t seconds for a key, return YES/NO/FAILURE */
	get_key()	/* return the key struck or FAILURE */
	close_keyboard()	/* tell the library you're through */

The result of getchar(), etc, between open_keyboard() and close_keyboard()
would be undefined, as would whether pending input was flushed.

This would keep raw I/O from interfering with stdio, and allow for systems
where setting/clearing modes is expensive and/or not transparent.

What does POSIX.1 do about this stuff?
-- 
Peter da Silva.  `-_-'  peter@ferranti.com
+1 713 274 5180.  'U`  "Have you hugged your wolf today?"