Getchar w/wout echo

Karl Heuer karl at haddock.ima.isc.com
Wed Sep 14 07:36:55 AEST 1988


mercer at ncrcce.StPaul.NCR.COM (Dan Mercer) writes:
>karl at haddock.ima.isc.com (Karl Heuer) writes:
>>mercer at ncrcce.StPaul.NCR.COM (Dan Mercer) writes:
>>>One shouldn't ... expect the interface of the language to the operating
>>>system to be the same in all instances.
>>
>>Why not?  That's exactly what stdio does, for example.
>
>To mutilate stdio to know the type of input device it is getting the stream
>from is a violation.

On some implementations, where completely different system calls control the
terminal and the disk, stdio already needs to know this.  (Even on UNIX, it
uses isatty() to decide which buffering scheme to use.)

>And in systems with distributed processing ... it isn't practical (what are
>you going to do, send out change ioctl commands with every character input).

If that's the only way to achieve the effect, then yes, that's what the
package has to do.  (Isn't that what the user would have to do, if he chooses
to roll his own?)  If there's a more efficient way, but it doesn't jive with
the model I proposed (rawenable(), getrawchar(), rawdisable()), then I'd like
to change the model to accommodate.  That's why I brought it up.

>Why don't you just find out how on your machine you turn off echo and roll
>your own programs to do stdio.  For your programs to be portable across
>different hardware schemes, and different operating systems, you'll just have
>to do what the rest of us do - write code to port them.

That's what I'm doing.  On various implementations, I'm finding out how to
turn off echo, and I'm encapsulating that information in a package.  I port
that package to different implementations, and any of my programs that need
the feature access it through this package.

So what do I end up with?  An interface of the language to the operating
system which is the same in all instances.

Karl W. Z. Heuer (ima!haddock!karl or karl at haddock.isc.com), The Walking Lint



More information about the Comp.lang.c mailing list