Path: utzoo!attcan!uunet!auspex!guy From: guy@auspex.auspex.com (Guy Harris) Newsgroups: comp.std.c Subject: Re: ReadKey like Function in C Message-ID: <2357@auspex.auspex.com> Date: 12 Aug 89 22:50:39 GMT References: <148@trigon.UUCP> <207600029@s.cs.uiuc.edu> <941@lakesys.UUCP> <21175@cup.portal.com> <3705@buengc.BU.EDU> <10712@smoke.BRL.MIL> <3727@buengc.BU.EDU> Reply-To: guy@auspex.auspex.com (Guy Harris) Organization: Auspex Systems, Santa Clara Lines: 45 >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.