Thread: Using getchar() to flush newline from input buffer

  1. #1
    Registered User
    Join Date
    Sep 2018
    Posts
    14

    Using getchar() to flush newline from input buffer

    I have looked up what getchar() does, which says it takes a single character input from the keyboard and returns the int value of it. It also does not read white spaces.

    With that in mind, I still don't understand why the following statement flushes the input buffer of any white spaces?

    while ( getchar() != '\n' && getchar()!=EOF);

    More specifically,
    1) If getchar() cannot read white spaces, how does it get rid of the newline in the input buffer?

    2) Why does the condition use != ?

    3) The fact that the rests of the code carries on after this statement, implies that the condition of the statement somehow always becomes true? I get that it becomes false if one presses the EOF, but does it also becomes false if one presses Enter on the keyboard since that amounts to \n?

  2. #2
    and the Hat of Guessing tabstop's Avatar
    Join Date
    Nov 2007
    Posts
    14,336
    getchar absolutely reads white spaces.

  3. #3
    Registered User
    Join Date
    Dec 2017
    Posts
    633
    Therefore your assumption must be wrong.
    In fact, getchar() does read whitespace (or any char whatsoever).
    The world hangs on a thin thread, and that is the psyche of man. - Carl Jung

  4. #4
    Registered User rstanley's Avatar
    Join Date
    Jun 2014
    Location
    New York, NY
    Posts
    671
    Quote Originally Posted by Valour549 View Post
    I have looked up what getchar() does, which says it takes a single character input from the keyboard and returns the int value of it. It also does not read white spaces.

    With that in mind, I still don't understand why the following statement flushes the input buffer of any white spaces?

    while ( getchar() != '\n' && getchar()!=EOF);

    More specifically,
    1) If getchar() cannot read white spaces, how does it get rid of the newline in the input buffer?

    2) Why does the condition use != ?

    3) The fact that the rests of the code carries on after this statement, implies that the condition of the statement somehow always becomes true? I get that it becomes false if one presses the EOF, but does it also becomes false if one presses Enter on the keyboard since that amounts to \n?
    getchar() should only be called once in the statement you present. The following is an example of the proper way:
    Code:
    int ch = 0;
    while ((ch = getchar()) != '\n' && ch != EOF);
    getchar(), is line buffered. You enter any number of characters until the [Enter] key is pressed. Then getchar() will input the first char in the buffer.

    Further calls to getchar() WILL read any character (Including ALL white-space chars) left in the buffer after a function such as scanf() up to and including the newline, or EOF if reading from a file or using redirection.

    Throw out whatever you were reading and get a good book on C Programming!!!

  5. #5
    Registered User
    Join Date
    Sep 2018
    Posts
    14
    Quote Originally Posted by rstanley View Post
    getchar() should only be called once in the statement you present. The following is an example of the proper way:
    Code:
    int ch = 0;
    while ((ch = getchar()) != '\n' && ch != EOF);
    getchar(), is line buffered. You enter any number of characters until the [Enter] key is pressed. Then getchar() will input the first char in the buffer.

    Further calls to getchar() WILL read any character (Including ALL white-space chars) left in the buffer after a function such as scanf() up to and including the newline, or EOF if reading from a file or using redirection.

    Throw out whatever you were reading and get a good book on C Programming!!!
    This still doesn't explain my third question though.

    So, let's pretend there is currently a newline in the buffer. The code then proceeds to

    Code:
    int ch = 0;
    while ((ch = getchar()) != '\n' && ch != EOF);
    Due to the (partial) statement ch = getchar(), now ch == '\n' and the program pauses because the condition for the while loop is false.

    But the fact is the program keeps going.

    So I can only conclude that for some reason, getchar() keeps giving ch a new value until said value is no longer '\n' or EOF. But why does it do that when there is only one getchar()?

  6. #6
    and the Hat of Guessing tabstop's Avatar
    Join Date
    Nov 2007
    Posts
    14,336
    You might have missed the semicolon at the end of the statement there -- that means that you have an "empty" while loop. That means that your guard condition (i.e. the part inside the while(--right here--)) is continually evaluated over and over and over and over and over and over and over and over ....

    Normally, that means infinite loop. But in this case, the guard condition has a side effect -- specifically, that call to getchar() gets evaluated over and over and over and over and over and over and over and over and over ..., each time taking one character with it from the input stream. Once you hit a \n character, or the stream gets empty (and thus getchar returns EOF), the && becomes false and the loop is ended.

  7. #7
    Registered User
    Join Date
    Sep 2018
    Posts
    14
    While we are on the topic of getchar(), it allegedly returns an int value. Yet:

    Code:
    int x;
    int main()
    {
        x=getchar(); // enter 3
        printf("%d\n",x); // prints out 51 instead
    }
    Code:
    int x;
    int main()
    {
        x=getchar(); // enter 3
        printf("%c\n",x); // prints out 3 correctly
    }
    Code:
    char x;
    int main()
    {
        x=getchar(); // enter 3
        printf("%d\n",x); // prints out 51 instead
    }
    Code:
    char x;
    int main()
    {
        x=getchar(); // enter 3
        printf("%c\n",x); // prints out 3 correctly
    }
    So it's clear that getchar() is returning the ASCII value, which is always an integer, as it always reads the input as a characters. But it seems like whether we declare int x or char x makes no difference at all? Does that mean in the above discussion, if we had written char ch instead of int c it would be equally valid?

  8. #8
    and the Hat of Guessing tabstop's Avatar
    Join Date
    Nov 2007
    Posts
    14,336
    EOF is (by definition in the C language anyway) some value that does not exist in ASCII and consequently can't be stored in a char.

    And even if you think you're only dealing with interactive input, (a) it is theoretically possible to send EOF from the console and (b) some clever soul might redirect input from a text file (and then you'll get EOF when the file runs out).

  9. #9
    Registered User
    Join Date
    Sep 2018
    Posts
    14
    Quote Originally Posted by tabstop View Post
    You might have missed the semicolon at the end of the statement there -- that means that you have an "empty" while loop. That means that your guard condition (i.e. the part inside the while(--right here--)) is continually evaluated over and over and over and over and over and over and over and over ....

    Normally, that means infinite loop. But in this case, the guard condition has a side effect -- specifically, that call to getchar() gets evaluated over and over and over and over and over and over and over and over and over ..., each time taking one character with it from the input stream. Once you hit a \n character, or the stream gets empty (and thus getchar returns EOF), the && becomes false and the loop is ended.
    No, I fully noticed the semicolon. I understood that it's a while loop with no body at all.

    The very strange thing is that while we usually put an evaluation as the condition
    Code:
    while (ch = != '\n' && ch != EOF);
    this time we have placed an assignment inside the condition
    Code:
    while ((ch = getchar()) != '\n' && ch != EOF);
    I guess it's this little trick that allows a single getchar() to perform itself multiple times until it bypasses any value we don't desire. I think this can be very useful in some situations where we want to filter out a number or character.

    But I'm still confused if there are any differences in declaring a variable int or char before assigning it getchar(), and if so, an example would be nice. (EDIT: ignoring EOF conditions...)

  10. #10
    Registered User
    Join Date
    Dec 2017
    Posts
    633
    A char is just a small integer. getchar() returns a larger integer than a char so that it can return a special value outside of the range of a char to represent EOF.

    One particular problem of using char is that it is not guaranteed to be signed and if it's unsigned then it's value of 255 will not equal EOF's value of -1.
    The world hangs on a thin thread, and that is the psyche of man. - Carl Jung

  11. #11
    Registered User
    Join Date
    Sep 2018
    Posts
    14
    Quote Originally Posted by john.c View Post
    A char is just a small integer. getchar() returns a larger integer than a char so that it can return a special value outside of the range of a char to represent EOF.

    One particular problem of using char is that it is not guaranteed to be signed and if it's unsigned then it's value of 255 will not equal EOF's value of -1.
    Why then does this example declare char c instead of int c?

    So it's safe to conclude that outside of EOF conditions, declaring the variable as int or char makes no difference at all, but since int is the more inclusive one, we should always declare the variable as an int?

  12. #12
    and the Hat of Guessing tabstop's Avatar
    Join Date
    Nov 2007
    Posts
    14,336
    The getchar() function will return (1) either something that fits in an (unsigned) char, or (2) EOF (which doesn't), so for any "valid" result you won't notice a difference. The bit pattern for any valid character will be the same (except the int will have a lot more zeroes in the front).

    If we're sticking with C, char is considered an "integral" type so it's in the same family, as it were, of the ints, and you're always in control of how you print it via the printf format string. If you end up in C++ some day, you don't have format options (for the most part) for output, so the type would determine how it is printed.

  13. #13
    and the Hat of Guessing tabstop's Avatar
    Join Date
    Nov 2007
    Posts
    14,336
    Quote Originally Posted by Valour549 View Post
    Why then does this example declare char c instead of int c?
    Somebody wasn't paying a lot of attention, probably. The blurb at the top is pretty specific about the int return (and why it's an int), and putchar expects an int rather than a char anyway (at least by official specs), so.

  14. #14
    Registered User
    Join Date
    May 2010
    Posts
    4,452
    One particular problem of using char is that it is not guaranteed to be signed and if it's unsigned then it's value of 255 will not equal EOF's value of -1.
    Yes, except that while EOF is usually -1 that is not always the case, the actual value is an implementation detail.

    From the C11 draft standard: N1548 Committee Draft — December 2, 2010 ISO/IEC9899:201x

    The header <ctype.h> declares several functions useful for classifying and mapping
    characters.198) In all cases the argument is an int, the value of which shall be
    representable as an unsigned char or shall equal the value of the macro EOF. If the
    argument has any other value, the behavior is undefined.
    And EOF is:
    EOF
    which expands to an integer constant expression, with type int and a negative value, that
    is returned by several functions to indicate end-of-file, that is, no more input from a
    stream;
    The actual value is not specified by the standard.

  15. #15
    Registered User
    Join Date
    Dec 2017
    Posts
    633
    Quote Originally Posted by jimblumberg View Post
    Yes, except that while EOF is usually -1 that is not always the case, the actual value is an implementation detail.
    I'm very well aware of that and it of course makes absolutely no difference to my point which was that a negative number will never equal a positive number.
    The world hangs on a thin thread, and that is the psyche of man. - Carl Jung

Popular pages Recent additions subscribe to a feed

Similar Threads

  1. Question on getchar to flush scanf
    By lotrfan in forum C Programming
    Replies: 1
    Last Post: 03-15-2012, 04:59 PM
  2. About Flush the input buffer
    By Laythe in forum C Programming
    Replies: 1
    Last Post: 04-15-2011, 09:21 AM
  3. clearing the buffer - but not the newline
    By Ash1981 in forum C Programming
    Replies: 13
    Last Post: 01-06-2006, 05:22 AM
  4. Flush Input Buffer
    By zx-1 in forum C Programming
    Replies: 41
    Last Post: 10-29-2005, 08:58 AM
  5. How to flush the buffer
    By Unregistered in forum C Programming
    Replies: 6
    Last Post: 07-26-2002, 03:28 AM

Tags for this Thread