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