Xref: utzoo comp.lang.c:36725 comp.std.c:4418
Path: utzoo!censor!geac!torsqnt!lethe!yunexus!ists!helios.physics.utoronto.ca!news-server.csri.toronto.edu!cs.utexas.edu!sun-barr!olivea!uunet!mcsun!ukc!inmos!conor@lion.inmos.co.uk
From: conor@lion.inmos.co.uk (Conor O'Neill)
Newsgroups: comp.lang.c,comp.std.c
Subject: Keyboard support in C (was Re: making characters disappear)
Message-ID: <14542@ganymede.inmos.co.uk>
Date: 28 Feb 91 13:41:26 GMT
References: <1991Feb23.014700.16507@ico.isc.com> <1991Feb19.015727.2223@to.rushpc> <1991Feb23.170142.538@ux1.cso.uiuc.edu> <15302@smoke.brl.mil>
Sender: news@inmos.co.uk
Reply-To: conor@inmos.co.uk (Conor O'Neill)
Organization: INMOS Limited, Bristol, UK.
Lines: 46

In article <15302@smoke.brl.mil> gwyn@smoke.brl.mil (Doug Gwyn) writes:
>In article <1991Feb23.170142.538@ux1.cso.uiuc.edu>
>>mcdonald@aries.scs.uiuc.edu (Doug McDonald) writes:
>>That is because it SHOULD be possible to do such very common things
>>as non-echo reading or reading single characters without terminating
>>carriage returns. We should be discussing how to put this into the
>>next standardized version of the language. It SHOULD have been in the
>>present version. 
>
>I don't think you would find many (if any) people among those who have
>carefully considered what needed to go into the C standard, who would
>agree with you.  This is clearly a very system-specific notion; there
>are C environments where the notion makes no sense.  The C standard
>addresses (for hosted environments only) just the minimum universally-
>implementable support necessary for useful applications across all
>hosted environments.  There are other standards, such as POSIX.1, that
>address more system-specific features, and that is an appropriate way
>to deal with them.

I agree strongly with Doug McDonald.
There is already a huge quantity of `system-specific' stuff in the hosted
version of ANSI C. Examples such as getenv and system spring to mind.
Since all computers which support files almost certainly have a keyboard,
it would seem sensible to provide for keyboard access within ANSI C.
I agree that some operating systems would not support un-buffered/echoed
input, but there again, some operating systems do not support
environment variables, the system function,
or access to the time of day, or...
The function ("inkey", or whatever it might be called) could simply
return an error code if it could not be supported.

It also seems, because of the frequency with which this question occurs,
that it is exactly the sort of problem which it would have been useful
to standardise, so that it would be possible to write interactive
programs which were at least portable to machines and operating systems
with `normal' keyboards.

(Standard disclaimer that ANSI C existed to standardise existing practice,
and not to introduce new ideas. It is unfortunate that a large proportion of
existing practice was UNIX, which has terrible support for keyboards).
(Sorry - pretend that I didn't say that!)

---
Conor O'Neill, Software Group, INMOS Ltd., UK.
UK: conor@inmos.co.uk		US: conor@inmos.com
"It's state-of-the-art" "But it doesn't work!" "That is the state-of-the-art".