Unexplainable behavior...

This is a discussion on Unexplainable behavior... within the C Programming forums, part of the General Programming Boards category; Hey guys, I'm writing a rudimentary program to explore the behavior of the stdin buffer and I've encountered something that ...

  1. #1
    Registered User
    Join Date
    Jan 2011
    Posts
    7

    Exclamation 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?
    Last edited by wpcarro; 01-06-2011 at 02:33 PM.

  2. #2
    Registered User whiteflags's Avatar
    Join Date
    Apr 2006
    Location
    United States
    Posts
    7,656
    OK well the correct way to send EOF looks something like this:
    0123456789
    ^Z
    Where ^Z represents the actual key combination you press to send it. 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.

    As for the way the input is printed, that is related to the EOF thing. Had you not tried to send EOF in the middle of an input operation, you would get one line of output like:
    0123456789
    If you really want to use EOF to break the loop I suggest changing readline:
    Code:
    int getLine(char read[])
    {
        int c, i;
        for ( i = 0; i < BYTESIZE - 1; i++ ) {
            c = getchar();
            if( c == EOF ) break;
            else read[i] = c;
        }
        read[i] = '\0';
        return 0;
    }
    I can at least guarantee that readline will exit in a timely matter, whether EOF is sent (either by you or by the computer), or you simply fill read.

    HTH, and please note that line numbers are very annoying. It makes a lot of work to copy or edit your code in anything.

  3. #3
    Registered User
    Join Date
    Jan 2011
    Posts
    7
    Thanks.
    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? Also, after reading your reply, I'm tempted to believe that checking for EOF signals for shell-level input is both inelegant and unnecessary. For a function like this, 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 and hopefully won't encounter any other variables. Can you see any potential problems with this?

  4. #4
    ATH0 quzah's Avatar
    Join Date
    Oct 2001
    Posts
    14,826
    Quote Originally Posted by whiteflags View Post
    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.
    Hope is the first step on the road to disappointment.

  5. #5
    Registered User whiteflags's Avatar
    Join Date
    Apr 2006
    Location
    United States
    Posts
    7,656
    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 *.
    Last edited by whiteflags; 01-06-2011 at 04:48 PM.

  6. #6
    Registered User whiteflags's Avatar
    Join Date
    Apr 2006
    Location
    United States
    Posts
    7,656
    Quote Originally Posted by quzah View Post
    You know this makes absolutely no sense at all, right?
    I figured it was wrong.

  7. #7
    Registered User
    Join Date
    Jan 2011
    Posts
    7
    CTRL C isn't EOF.
    I am aware that CTRL + c is not a keystroke used to produce an EOF signal. The only reason I mentioned that I was terminating the program using CTRL + c was to explain that I am manually terminating the program because the function itself returns 1 in every circumstance.
    The reason that this function was checking for an EOF was not for program termination, but because I was merely mimicking what I had seen in the program examples presented in the K&R book.
    Also, this function was simply designed to handle user-input at the shell level. Its purpose was to teach me more about the way the stdin buffer behaved. I understand that a well-designed program should be able to handle a variety of input streams, however, since I am only concerned with direct input via the shell, then it seems suitable to forgo checking for EOFs.

Popular pages Recent additions subscribe to a feed

Similar Threads

  1. fork behavior
    By jlotty in forum C Programming
    Replies: 2
    Last Post: 12-13-2009, 09:50 PM
  2. Strange string behavior
    By jcafaro10 in forum C Programming
    Replies: 2
    Last Post: 04-07-2009, 07:38 PM
  3. Normal iterator pointer behavior
    By SevenThunders in forum C++ Programming
    Replies: 9
    Last Post: 04-01-2008, 12:11 PM
  4. really weird behavior, 16 bit asm w/masm
    By BobMcGee123 in forum A Brief History of Cprogramming.com
    Replies: 7
    Last Post: 12-01-2005, 05:45 PM
  5. Game Design Topic #1 - AI Behavior
    By TechWins in forum Game Programming
    Replies: 13
    Last Post: 10-11-2002, 10:35 AM

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21