Path: utzoo!utgpu!water!watmath!clyde!ima!haddock!karl From: karl@haddock.ima.isc.com (Karl Heuer) Newsgroups: comp.lang.c Subject: Re: Echoing chars and input functions Message-ID: <6233@haddock.ima.isc.com> Date: 18 Aug 88 16:38:12 GMT References: <8808160751.aa03016@SMOKE.BRL.MIL> <8349@smoke.ARPA> <2821@boulder.Colorado.EDU> Reply-To: karl@haddock.isc.com (Karl Heuer) Organization: Interactive Systems, Boston Lines: 26 In article <2821@boulder.Colorado.EDU> swarbric@tramp.Colorado.EDU (Frank Swarbrick) writes: >In article <8349@smoke.ARPA> gwyn@brl.arpa (Doug Gwyn (VLD/VMB)) writes: >>[The correct way to input a character, with echo when necessary, is] >> c = getchar(); > >I could have sworn someone said their compiler did not echo the character when >they used this. Did I misunderstand someone, or is their compiler just >non-conformant (broken)? Since the compiler in question did echo when using fgets, it is indeed broken according to the dpANS (which specifies that all I/O functions behave as if they use getc/putc as primitives). Now, it would be valid and conforming for the implementation to *never* echo. There's nothing wrong with this; Unix programs generally do this if you've put the terminal in noecho mode before starting the program. But if this would make C programs behave in a manner which is non-intuitive for the system in question, then it's a poor quality implementation. It's obvious that stdio should use, as it's lowest-level primitive, whatever is the natural I/O mechanism of the host. No, the dpANS doesn't *force* this. But, to paraphrase the Rationale, "It's possible to create an implementation which conforms to the letter of the Standard and yet is useless." Karl W. Z. Heuer (ima!haddock!karl or karl@haddock.isc.com), The Walking Lint