Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!iuvax!uxc.cso.uiuc.edu!tank!mimsy!chris From: chris@mimsy.UUCP (Chris Torek) Newsgroups: comp.std.c Subject: Re: ReadKey like Function in C Message-ID: <19070@mimsy.UUCP> Date: 14 Aug 89 17:29:19 GMT References: <148@trigon.UUCP> <207600029@s.cs.uiuc.edu> <941@lakesys.UUCP> <3727@buengc.BU.EDU> Organization: U of Maryland, Dept. of Computer Science, Coll. Pk., MD 20742 Lines: 56 In article <3727@buengc.BU.EDU> bph@buengc.BU.EDU (Blair P. Houghton) writes: >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()... For one thing, this statement is partly false: compiler writers are not in a position to choose the most appropriate way from {wait up to .3 seconds for a key, send a signal on key,}, and so cannot provide the version most suited to any particular application. (Many games, for instance, want `wait for key with timeout'; many want `wait forever for key'; many want `do not wait for key'; but still others want something else entirely.) >Makes me wonder why they haven't, ANSI or no. Imagine you are the president of IBM or Unisys. You have $100 billion worth of customers running systems that treat people like virtual card punches. 1% of them want ANSI C. If ANSI C includes a mandatory ReadKey (whatever it does---all we know for certain at this point is that it is not compatible with card readers), you will have to commit many $ to upgrading these systems; if it does not, all you need do is commit a few $ to writing an ANSI-conformant compiler and runtime system for these systems. In return for either effort, you will get about $1 billion worth of business. Which do you prefer: to spend about $999+ milllion in return for your $1 billion (upgrade all those systems, losing the customers who will not upgrade), or to spend about $1 million in return for your $1 billion (writing, testing, and supporting compilers for all those systems)? ----- Now imagine you are the user on the receiving end of one of these virtual-card-punch systems. If ANSI puts a ReadKey function (whatever it does; all we know is that your system cannot do it) into the standard, IBM will not bother attempting to earn a few bucks by upgrading your system and then providing an ANSI C, but if ANSI does not put a ReadKey function into the standard, IBM will provide a C compiler. Which do you prefer: to have no C compiler at all, or to have one without a standard ReadKey? ----- This is, of course, an oversimplification of the issue; but the point is that this standard is intended to be used in places where ReadKey cannot be done; therefore this standard cannot say that ReadKey must be done. You might prefer a standard that is not so accomodating: you never touch these systems, for you want a nicer environment than they could ever provide. Such standards can and do exist, either unrelated to, or `sitting above', the language standard. The POSIX 1003.1 standard, for instance, tells you how to write a nearly infinite variety of different ReadKey-like functions in C. All of them will work on all POSIX 1003.1-conformant systems. -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163) Domain: chris@mimsy.umd.edu Path: uunet!mimsy!chris