K&R2, 1.5.1 example

[arnuld]

/* K&R@, 1.5.1 - File Copying */

#include<stdio.h>

int main()
{
int c;

while((c = getchar())!= EOF)
putchar(c);

return 0;
}

--------- OUTPUT -----------
[arch@voodo kr2]$ gcc -ansi -pedantic -Wall -Wextra 1.5.1_file-
copying.c
[arch@voodo kr2]$ ./a.out
like this
like this
and thia
and thia
[arch@voodo kr2]$



you can see that "putchar" prints something only after hitting the
newline. this is exactly in agreement with what K&R2 says at the
beginning of section 1.5:

"Text input or output, regardless of where it originates or where it
goes to, is dealt with as streams of characters. A text stream is a
sequence of characters divided into lines; each line consists of zero
or more characters followed by a newline character"

whereas at the beginning of section 1.5.1 K&R2 says:

"The simplest example is a program that copies its input to its output
one character at a time"

these statements are exactly opposite to each other. i am confused
about this. looking at the code conforms that we are printing only one
character at a time whereas running the code shows that it is printing
a line at a time, rather than one character at a time. how does it
work ?

 

[Richard Heathfield]

arnuld said:

looking at the code conforms that we are printing only one
character at a time whereas running the code shows that it is printing
a line at a time, rather than one character at a time. how does it
work ?

C is doing the actual copying of characters, and it is indeed doing them
one character at a time.

Your system is doing the display of data on the output device, and it is
indeed doing them one line at a time (i.e. it's 'buffering' the data).

 

[arnuld]

C is doing the actual copying of characters, and it is indeed doing them
one character at a time.

Your system is doing the display of data on the output device, and it is
indeed doing them one line at a time (i.e. it's 'buffering' the data).

you want to say that:

1.) C programme is taking input 1 character at a time but this is the
compiler that storing the input into, what you call, a "buffer".

2.) when compiler finds the next character as '\n', it puts that whole
buffer onto the standard output, my terminal.

3.) so compiler is the cause of confusion not the code.

 

[Richard Heathfield]

arnuld said:

you want to say that:

1.) C programme is taking input 1 character at a time but this is the
compiler that storing the input into, what you call, a "buffer".

No, the compiler isn't even *running* at the stage where the data is
being handled. This is nothing to do with your compiler. It's the
system - your bash shell or Windows console or Mac colouring-box or
whatever you're using - that is dealing with input on a line-by-line
level.

When your program requests a character, the shell is collecting an
entire line from the user, and then giving the first character of that
line to your program, which is then free to go and process it.

When your program requests the next character, the shell can hand it
over straight away because it's still got a whole bunch of stuff ready.

Only when it runs out of data (i.e. has handed over the whole line, some
calls later) will it go back to the user for more.

Same in reverse when displaying. Your program hands over a character for
printing, and the shell grabs the character, says "thank you very
much", and does ***nothing at all*** with it - until it is either given
a newline or explicitly told to stop messing about and get on with it,
at which point it will write out everything it has saved up so far.

 

[santosh]

you want to say that:

1.) C programme is taking input 1 character at a time but this is the
compiler that storing the input into, what you call, a "buffer".

2.) when compiler finds the next character as '\n', it puts that whole
buffer onto the standard output, my terminal.

3.) so compiler is the cause of confusion not the code.

No. The compiler has compiled whatever you've asked it to compile and
the code is doing exactly what it appears to be doing. However your
program has a host environment and this host, or operating system is
buffering input and output to and from your program.

When you type in characters at the keyboard, they're typically
collected in a system level buffer and sent to the program only when
you signal an end-of-line, i.e. by pressing the Enter key. This is the
default behaviour of most operating systems, since it gives you a
chance to correct your typing errors and otherwise edit your command
line. All this occurs beyond the reach of your C program and all the
latter can do is block until the system decides to deliver the input.

There're implementation and system specific ways to "turn off" this
behaviour and grab input character by character as soon as the they
appear from the associated device. But because these details vary from
system to system and some systems lack such ability, the C Standard
library was based around a buffered model.

There's also another level of buffering going on - one by the C
Standard library. This is typically "line buffered" for stdin.
There're also options for fully turning on or turning off buffering
with the setvbuf function, but this is not necessary in most cases.
The defaults are fine.

Similarly stdout is line buffered by default, i.e. the stream's
buffers are flushed and the content sent to the associated output
device when a complete line has been recieved. That's why there's the
constant advice to terminate the strings to printf with a newline.
Otherwise output may not appear immediatly. Of course calling
fflush(stdout) causes a immediate write. Likewise streams connected to
disk files are fully buffered by default, i.e., content is written
when the buffer becomes full. Again, you can control this buffering
with setvbuf though in most cases the defaults are good enough.

The operating system may or may not have further buffers of it's own
for output from your program. All that's guaranteed in a Standard C
program is what's spelt out in the Standard.