Thread: 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?

getchar absolutely reads white spaces.

Originally Posted by Valour549

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!!!

Originally Posted by rstanley

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()?

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.

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?

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).

Originally Posted by tabstop

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...)

Originally Posted by john.c

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?

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.

Originally Posted by Valour549

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.

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.