bill@proxftl.UUCP (T. William Wells) (08/26/88)
In article <65071@sun.uucp> swilson@sun.UUCP (Scott Wilson) writes:
: Making a window look
: like a terminal is a function of the C libraries.
Agreed. And your compiler is broken for not doing this
correctly. I know that doesn't help you but I can suggest a
kludge:
If you use getchar() exclusively, you might be able to avoid the
problem by modifying stdio.h. You see, getchar is often
implemented as a macro:
#define getchar() getc(stdin)
or some such. You could edit your stdio.h so that the macro is
something like:
#define getchar() (putchar(getchar()))
This has the advantage of leaving your program portable but the
disadvantage of using a non-standard configuration for your
compiler (watch those upgrades!). And, if you slip and use
something else, you'll get surprised.
: My question is how do we get getchars that behave similarly
: on different systems when for some implementations it falls under the
: responsibility of the C libraries because the OS doesn't have terminal
: support.
The way you get such getchars is to buy the compiler that
provides them. I'm serious. You got screwed by this compiler
implementer (I'll take that back if they fix this bug).
Standards will *not* fix the problem if the implementers do not
adhere to them.
As for interactive terminals, I do not know of *any* other system
that does not provide echoing under normal circumstances when one
does getchar(). (No doubt that will provoke a flood of
counterexamples. So be it.) Your apparent lack of uniformity
appears to be an artifact of a compiler that fails to conform to
the de facto standards. You certainly can't complain if it fails
to conform to the ANSI standard, as that *does not* exist. Yet.
It does appear to be the case that the *proposed* ANSI standard
is somewhat, shall we say, concise :-) when defining interactive
devices. Here are the relevant passages.
Rationale 2.1.2.3:
"The class of *interactive devices* is intended to include at
least asynchronous terminals, or paired display screens and
keyboards. An implementation may extend the definition to
include other input and output devices or even network
inter-program connections, provided they obey the Standard's
characterization of interactivity."
2.1.2.3:
"The input and output dynamics of interactive devices shall take
place as specified in 4.9.3. The intent of these requirements is
that unbuffered or line-buffered output appear as soon as
possible, to ensure that prompting messages actually appear prior
to a program waiting for input.
What constitutes an interactive device is
implementation-defined."
4.9.3:
"... are fully buffered if and only if the stream can be
determined not to refer to an interactive device."
4.9.5.3:
"... is fully buffered if and only if the stream can be
determined not to refer to an interactive device."
And that, I am afraid, would seem to be all.
To clarify this for those on comp.std.c (to which this has been
cross-posted), the original complaint was that his compiler's
getchar() does not echo characters! I agree with him that an
interactive device ought to be defined as one intended to provide
echoing of some kind of the user's input.
The third draft does not seem to say anything like this. Does
anyone out there have any additional information? If not, I'll
ask that they add this to the standard. It ought to be
acceptable, as this would seem to be an editorial change -- is it
interactive if you can't see your input??!
---
Bill
novavax!proxftl!bill