swilson%thetone@Sun.COM (Scott Wilson) (07/30/88)
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
gwyn@brl-smoke.ARPA (Doug Gwyn ) (07/30/88)
In article <62114@sun.uucp> swilson%thetone@Sun.COM (Scott Wilson) writes: >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? None of the input functions is specified as performing any output operation (except that input from an interactive device, whatever that means, will first cause buffered STDIO output for that device to be fflushed). It is not within the scope of the ANSI C Standard to specify such details of the operating system as you are asking about. In fact it really isn't considered the C library's job to perform echoing of terminal input, but if you have a mickey-mouse operating system then a quality implementation will have to compensate for its deficiencies. I would have expected yours to have provided ways to switch into and out of "input canonicalization" mode in its terminal input support. Even Apple II Aztec C does that.
karl@haddock.ISC.COM (Karl Heuer) (08/01/88)
In article <62114@sun.uucp> swilson%thetone@Sun.COM (Scott Wilson) writes: >[On some deficient OS and/or C library, getchar() doesn't echo or allow >backspacing. Also scanf has the same problem.] > >(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. So getchar() was a macro? I bet your solution didn't solve the scanf() problem, then, unless you recompiled. >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.) Now this *is* in violation of the Standard. All of the I/O functions are supposed to behave as if by repeated calls to fgetc/fputc. Echo and erase should either be enabled in getchar(), or disabled in fgets(). Karl W. Z. Heuer (ima!haddock!karl or karl@haddock.isc.com), The Walking Lint