Thread: Unexplainable behavior...

Hey guys,
I'm writing a rudimentary program to explore the behavior of the stdin buffer and I've encountered something that I cannot make much sense of. The code simply takes input from the shell level and thus stores it in stdin, then the reads the input one char at a time, stores it into an array, and prints of the contents of that array to stdout. The way the getline function is designed to operate is to read chars from the stdin until a newline char, '\n', an EOF signal is reached, or until the for-loop counter value exceeds BUFF_SIZE - 2 (8). Once these are read, it then appends the newline char and the NULL byte char, '\0', to the array and returns 1 to the main function (I terminate the program manually using CTRL + C keystroke combination).

Code:

  1 #include <stdio.h>
  2 
  3 #define BUFF_SIZE 10
  4 
  5 int getLine(char buff[]);
  6 
  7 main()
  8 {
  9     char line[BUFF_SIZE];
 10 
 11     while(getLine(line) != 0)
 12         printf("%s", line);
 13 
 14     return 0;
 15 }
 16 
 17 int getLine(char read[])
 18 {
 19     int i, c;
 20 
 21     for(i = 0; i < BUFF_SIZE - 2; ++i) {
 22         c = getchar();
 23         if(c == EOF || c == '\n')
 24             break;
 25         read[i] = c;
 26     }
 27     read[i++] = '\n';
 28     read[i] = '\0';
 29 
 30     return 1;
 31 }

Now for the problem...For when I enter the char sequence: 0123456789 and press Enter the output reflects exactly how I expected it to. However, when I enter the char sequence: 0123456789 and send the EOF signal (CTLR + d) the program behaves somewhat unexpectedly. It will successfully print the first "01234567" string of chars, but then the remaining "89EOF" is not printed until I send press Enter. If you look at the source code, this is not how the program should execute so I am wondering what exactly is happening. It should replace the EOF with a newline char and append the NULL byte char and proceed to print this string, but it's almost as if it's waiting for me to prompt it, by pressing the Enter key, to do so. Can anyone help me figure this out?

Originally Posted by whiteflags

The way it looks is unimportant but the fact that it's on it's own line is important. EOF has to be one of the only things you send in response to an input prompt in order for it to work. I don't think this is a language thing, I think it is an environment thing in place to prevent mistakes. (What if 01234^Z is unintentional?). With files, you don't have to worry about when EOF is sent.

You know this makes absolutely no sense at all, right? Because streams (you typing, or it coming from a piped file or something) are all the same as far as C is concerned. It doesn't care if you're typing on a keyboard or reading from a disk. The real problem was this:

I terminate the program manually using CTRL + C keystroke combination

CTRL C isn't EOF.


Quzah.

So you're saying that the proper way for EOFs signals to be sent is on an individual line of their own, is that correct?

No, just pay attention to what quzah said. CTRL C is not EOF.

since the environment I am running it only accepts input that is line-buffered, it seems as if the only way the end of a line will be denoted is with the newline char. Therefore, I'm assuming that I should only be checking for that character ... Can you see any potential problems with this?

Yes. EOF means end of file and there is really no two ways about it. Well tested input routines ought to accept input from files as well, since stdin itself is a FILE *.