Echoing chars and input functions

[Doug Gwyn]

In article <2821 at boulder.Colorado.EDU> swarbric at tramp.Colorado.EDU (Frank Swarbrick) writes:
>In article <8349 at smoke.ARPA> gwyn at brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>) writes:
>>In article <8808160751.aa03016 at SMOKE.BRL.MIL> dsill at NSWC-OAS.ARPA (Dave Sill) writes:
>>>What, then, is the portable way to input a character from standard input,
>>>echoing the character to the screen when necessary?
>>We already answered that!  It's
>>	c = getchar();
>I could have sworn someone said their compiler did not echo the character when
>they used this.

How could the COMPILER do diddly about a character received at run time?
It's not even running at that point.

The point is, at the abstract machine level, which is the target for C
application source code, getchar() simply returns the next character from
standard input.  No other portable method (other than fully equivalent
getc(), scanf(), and fscanf() invocations) is available for this.
WHATEVER extra stuff is associated with getting an input character (e.g.
echoing) is dealt with somewhere else, not by the C application code.  For
example, the C library may have to determine where characters are coming
from and possibly echo them as they are typed, also providing a cursor and
input line editing and any other user-oriented features that are not
already provided at a lower level than the C library.  Most operating
systems will do this before the characters reach the C library, but some
may be deficient so that the C library has to take care of such details.
In any case, getchar() is all that is necessary at the C application
programming level.

Notice that many interactive applications need for input characters to NOT
be echoed.  Usually this is arranged by first asking the operating system
(or a part of the C library, if it's performing terminal handler functions)
to turn off input echoing.  On UNIX this is done via a certain ioctl()
system call; on other systems a different method may be necessary.