ANSI C and standard libraries
Scott Wilson
swilson%thetone at Sun.COM
Sat Jul 30 07:49:07 AEST 1988
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
More information about the Comp.std.c
mailing list