Getchar w/wout echo

[Karl Heuer]

Okay, we know that ANSI didn't standardize a raw-character input function.
Some have expressed the opinion that they couldn't, because such functionality
is not univerally available.  I disagree: they could easily specify that the
function is allowed to return a failure code.  (Note that the time() function
must exist on all ANSI implementations, but is permitted to return (time_t)-1
if there isn't a system clock.)  Let's try to design an appropriate interface.

Let's begin by ignoring the issue of exactly what "raw" means, and whether it
applies to the real terminal despite redirection, or to stdin or a stream of
the user's choice.  We can argue that out later.  We need a minimum of three
functions, which I'll call rawenable(), rawdisable(), getrawchar().

The system is always in one of two states, cooked or raw, with the initial
state being cooked.  (This does not imply that echoing occurs or that line
editing is possible; it's simply a name for the initial state.)  rawenable()
and rawdisable() change the state from cooked to raw or from raw to cooked,
respectively; if called from the "wrong" state, the behavior is undefined.  If
the implementation is unable to honor the request (because there is no OS
support for raw input, or because there is no terminal attached), the function
returns -1; otherwise it returns 0.

If getrawchar() is called from cooked mode, or any stdio function from raw
mode, the behavior is undefined.  When there are unread characters in the
stdin stream (as a result of ungetc() or OS-level line buffering), it is
implementation-defined whether getrawchar() behaves like getchar() or acts
independently of stdio.

In practice, some implementations will make rawenable() and rawdisable()
no-ops, and getrawchar() a system call; others will put the system calls into
rawenable() and rawdisable(), and make getrawchar() a synonym for getchar().
The model is designed to allow efficient implementation on a wide variety of
architectures.

This is a first cut at a solution; it can probably be improved.  Comments?

Karl W. Z. Heuer (ima!haddock!karl or karl at haddock.isc.com), The Walking Lint