🚀 go-pugleaf

How far will ANSI C go to define the behavior of standard libraries?  As
an example let me describe my problem:

I have tried porting some C programs orignally running under UNIX to
the Mac using LightspeedC.  The problem comes from the different
behavior of stdio calls.  These differences are so significant (I think)
that I have to do lots of silly stuff with #ifdef's and that's exactly
what I would expect a standard to alleviate.  According to the
Lightspeed 3.0 Standard Libraries Reference:

	getchar() gets the next character from stdin.  The character
	is not echoed to stdout.

This lack of echoing makes interactive programs using getchar rather
useless without modification.  What I found even more surprising is
that scanf (at least with LSC 2.15) didn't echo either; doing your
own echoing for getchar isn't too difficult but scanf is a problem.
Also no input processing could be done, i.e., you couldn't backspace
over an (invisible) typo.  The behavior is very similar to UNIX in
raw mode.

So the question is this:  what does ANSI C say about the behavior of
library routines?  Can I expect it to be defined that when using
getchar the user will see what he/she types?  And have a chance to
correct mistakes (which you also can't do with LSC)?  I realize that
with some implementations, such as UNIX, the behavior of the terminal
driver is set independently of the C environment so getchar cannot
guarantee echoing and error correction.  However, does ANSI C need
to state that under default terminal settings getchar will echo?
What about specifying that character erase or line erase facilties
are available?

(The way I solved this particular problem in LSC was to #undef
getchar, define it be "realgetc", and write realgetc to behave
like I thought it should.  Writing realgetc was easy because fgets
does echo characters and allow character erase, so I would just
fill a buffer with fgets and hand out one character at a time
when realgetc was called.)

Scott Wilson