Buffers

I l @ ve RuBoard

When you run the previous program on some systems, the text you input is echoed immediately. That is, a sample run would look like this:

 HHeelllloo,,  tthheerree..  II  wwoouulldd[enter] lliikkee  aa  #

The preceding behavior is the exception. On most systems, nothing happens until you press Enter, as in the first example. The immediate echoing of input characters is an instance of unbuffered (or direct ) input, meaning that the character you type is immediately made available to the waiting program. The delayed echoing, on the other hand, illustrates buffered input, in which the characters you type are collected and stored in an area of temporary storage called a buffer. Pressing Enter causes the block of characters (or single character, if that is all you typed) to be made available to your program. Figure 8.1 compares these two kinds of input.

Figure 8.1. Buffered versus unbuffered input.

Why have buffers? First, it is less time-consuming to transmit several characters as a block than to send them one by one. Second, if you mistype, you can use your keyboard correction features to fix your mistake. When you finally press Enter, you can transmit the corrected version.

Unbuffered input, on the other hand, is desirable for some interactive programs. In a game, for instance, you would like each command to take place as soon as you press a key. Therefore, both buffered and unbuffered input have their uses.

Buffering comes in two varieties: fully buffered I/O and line-buffered I/O. For fully buffered input, the buffer is flushed (the contents are sent to their destination) when it is full. This kind of buffering usually occurs with file input. The buffer size depends on the system, but 512 bytes and 4,096 bytes are common values. With line-buffered I/O, the buffer is flushed whenever a newline character shows up. Keyboard input is normally line-buffered, so that pressing Enter flushes the buffer.

Which kind of input do you have: buffered or unbuffered? ANSI C specifies that input should be buffered, but K&R left the choice open to the compiler writer. You can find out by running the echo.c program and seeing which behavior results.

The reason ANSI C settled on buffered input as the standard is that some computer designs don't permit unbuffered input. If your particular computer does allow unbuffered input, most likely your C compiler offers unbuffered input as an option. Compilers for IBM PC compatibles, for example, typically supply a special family of functions, supported by the conio.h header file, for unbuffered input. These functions include getche() for echoed unbuffered input and getch() for unechoed unbuffered input. ( Echoed input means the character you type shows onscreen, and unechoed input means the keystrokes don't show.) UNIX systems use a different approach, for there UNIX itself controls buffering. With UNIX, you use the ioctl() function to specify the type of input you want, and getchar () behaves accordingly . In ANSI C, the setbuf () and setvbuf () functions (see Chapter 12, "File Input/Output" ) supply some control over buffering, but the inherent limitations of some systems can restrict the effectiveness of these functions. In short, there is no standard ANSI way of invoking unbuffered input; the means depend on the computer system. In this book, with apologies to our unbuffered friends , we assume you are using buffered input.

I l @ ve RuBoard