ReadKey like Function in C

[Guy Harris]

>The Compiler writers are in a much better position to implement
>it than are a bunch of fractious C programmers arguing over
>whether to use fstat() or ioctl() and the length of timeout()...

A compiler writer stuck with an operating system that supports only,
say, block-mode terminals that transmit nothing to the host until an
ENTER key is pressed, and that cannot be made to do otherwise, is in
*no* position to implement said function.

The standards committee really isn't in a good position to tell vendors of
such systems to take a flying leap, either.  The POSIX committee is in a
better position to do so, since the scope of the POSIX standard is
larger than that of the C standard.

A question to those who want thus-and-such a feature in C, rather than
in, say, POSIX: what criterion do you use to distinguish between "stuff
the C standard should require" and "stuff the C standard should leave to
things like POSIX?"  If you say the second set should be empty, what do
you propose to do about people who want to write C applications that
*don't* need the particular features in question and want or need to
have them work on systems that make it difficult or impossible to
implement said features?

(Or, to put it another way: do you think there is a role both for the
ANSI C standard and for POSIX, and if not, why not?  I, and probably a
lot of the people on the committee, *do* think there are roles for both;
the C standard is for a language that can be implemented on a wide range
of machines under a wide range of operating systems, providing some
basic I/O capabilities but *not* providing the ability to do somewhat
device-specific things like run in "character-at-a-time mode", while the
POSIX standard is for an interface, currently in C (but other bindings
are under development) to operating system services on what is probably
a smaller range of machines and operating systems, possibly excluding
e.g. some of the older mainframe OSes.)

In fact, another question for those who want thus-and-such a feature in
C: why are we all better off with it there, than in POSIX?  The ability
to do character-at-a-time I/O *and* non-blocking versions of same on
terminals is *already* in POSIX; many non-UNIX operating systems vendors
are planning to implement POSIX atop their OSes.  It might not be
possible to do so atop, say, MS-DOS, but in that case it might be better
to consider either a *de jure* or *de facto* standard "subset" of POSIX
that may include some of the "termio" functions but not include "fork"
than to burden the C standard with functions that might be difficult or
impossible to implement on, say, the older mainframe OSes mentioned above.