I have the following program:
int main(int argc, char *argv[])
{
char ch1, ch2;
printf("Input the first character:"); // Line 1
scanf("%c", &ch1);
printf("Input the second character:"); // Line 2
ch2 = getchar();
printf("ch1=%c, ASCII code = %d\n", ch1, ch1);
printf("ch2=%c, ASCII code = %d\n", ch2, ch2);
system("PAUSE");
return 0;
}
As the author of the above code have explained:
The program will not work properly because at Line 1, when the user presses Enter, it will leave in the input buffer 2 character: Enter key (ASCII code 13) and \n (ASCII code 10). Therefore, at Line 2, it will read the \n and will not wait for the user to enter a character.
OK, I got this. But my first question is: Why the second getchar() (ch2 = getchar();) does not read the Enter key (13), rather than \n character?
Next, the author proposed 2 ways to solve such probrems:
use fflush()
write a function like this:
void
clear (void)
{
while ( getchar() != '\n' );
}
This code worked actually. But I cannot explain myself how it works? Because in the while statement, we use getchar() != '\n', that means read any single character except '\n'? if so, in the input buffer still remains the '\n' character?
The program will not work properly because at Line 1, when the user presses Enter, it will leave in the input buffer 2 character: Enter key (ASCII code 13) and \n (ASCII code 10). Therefore, at Line 2, it will read the \n and will not wait for the user to enter a character.
The behavior you see at line 2 is correct, but that's not quite the correct explanation. With text-mode streams, it doesn't matter what line-endings your platform uses (whether carriage return (0x0D) + linefeed (0x0A), a bare CR, or a bare LF). The C runtime library will take care of that for you: your program will see just '\n' for newlines.
If you typed a character and pressed enter, then that input character would be read by line 1, and then '\n' would be read by line 2. See I'm using scanf %c to read a Y/N response, but later input gets skipped. from the comp.lang.c FAQ.
As for the proposed solutions, see (again from the comp.lang.c FAQ):
How can I flush pending input so that a user's typeahead isn't read at the next prompt? Will fflush(stdin) work?
If fflush won't work, what can I use to flush input?
which basically state that the only portable approach is to do:
int c;
while ((c = getchar()) != '\n' && c != EOF) { }
Your getchar() != '\n' loop works because once you call getchar(), the returned character already has been removed from the input stream.
Also, I feel obligated to discourage you from using scanf entirely: Why does everyone say not to use scanf? What should I use instead?
You can do it (also) this way:
fseek(stdin,0,SEEK_END);
A portable way to clear up to the end of a line that you've already tried to read partially is:
int c;
while ( (c = getchar()) != '\n' && c != EOF ) { }
This reads and discards characters until it gets \n which signals the end of the file. It also checks against EOF in case the input stream gets closed before the end of the line. The type of c must be int (or larger) in order to be able to hold the value EOF.
There is no portable way to find out if there are any more lines after the current line (if there aren't, then getchar will block for input).
The lines:
int ch;
while ((ch = getchar()) != '\n' && ch != EOF)
;
doesn't read only the characters before the linefeed ('\n'). It reads all the characters in the stream (and discards them) up to and including the next linefeed (or EOF is encountered). For the test to be true, it has to read the linefeed first; so when the loop stops, the linefeed was the last character read, but it has been read.
As for why it reads a linefeed instead of a carriage return, that's because the system has translated the return to a linefeed. When enter is pressed, that signals the end of the line... but the stream contains a line feed instead since that's the normal end-of-line marker for the system. That might be platform dependent.
Also, using fflush() on an input stream doesn't work on all platforms; for example it doesn't generally work on Linux.
But I cannot explain myself how it works? Because in the while statement, we use getchar() != '\n', that means read any single character except '\n'?? if so, in the input buffer still remains the '\n' character???
Am I misunderstanding something??
The thing you may not realize is that the comparison happens after getchar() removes the character from the input buffer. So when you reach the '\n', it is consumed and then you break out of the loop.
you can try
scanf("%c%*c", &ch1);
where %*c accepts and ignores the newline
one more method
instead of fflush(stdin) which invokes undefined behaviour you can write
while((getchar())!='\n');
don't forget the semicolon after while loop
scanf is a strange function, and there's a classic line from the movie WarGames that's relevant: "The only winning move is not to play".
If you find yourself needing to "flush input", you have already lost. The winning move is not to search desperately for some magic way to flush the nettlesome input: instead, what you need to do is to do input in some different (better) way, that doesn't involve leaving unread input on the input stream, and having it sit there and cause problems, such that you have to try to flush it instead.
There are basically three cases:
You are reading input using scanf, and it is leaving the user's newline on the input stream, and that stray newline is wrongly getting read by a later call to getchar or fgets. (This is the case you were initially asking about.)
You are reading input using scanf, and it is leaving the user's newline on the input stream, and that stray newline is wrongly getting read by a later call to scanf("%c").
You are reading numeric input using scanf, and the user is typing non-numeric text, and the non-numeric text is getting left on the input stream, meaning that the next call to scanf fails on it also.
In all three cases, it may seem like the right thing to do is to "flush" the offending input. And you can try, but it's cumbersome at best and impossible at worst. In the end I believe that trying to flush input is the wrong approach, and that there are better ways, depending on which case you were worried about:
In case 1, the better solution is, do not mix calls to scanf with other input functions. Either do all your input with scanf, or do all your input with getchar and/or fgets. To do all your input with scanf, you can replace calls to getchar with scanf("%c") — but see point 2. Theoretically you can replace calls to fgets with scanf("%[^\n]%*c"), although this has all sorts of further problems and I do not recommend it. To do all your input with fgets even though you wanted/needed some of scanf's parsing, you can read lines using fgets and then parse them after the fact using sscanf.
In case 2, the better solution is, never use scanf("%c"). Use scanf(" %c") instead. The magic extra space makes all the difference. (There's a long explanation of what that extra space does and why it helps, but it's beyond the scope of this answer.)
And in case 3, I'm afraid that there simply is no good solution. scanf has many problems, and one of its many problems is that its error handling is terrible. If you want to write a simple program that reads numeric input, and if you can assume that the user will always type proper numeric input when prompted to, then scanf("%d") can be an adequate — barely adequate — input method. But perhaps your goal is to do better. Perhaps you'd like to prompt the user for some numeric input, and check that the user did in fact enter numeric input, and if not, print an error message and ask the user to try again. In that case, I believe that for all intents and purposes you cannot meet this goal based around scanf. You can try, but it's like putting a onesie on a squirming baby: after getting both legs and one arm in, while you're trying to get the second arm in, one leg will have wriggled out. It is just far too much work to try to read and validate possibly-incorrect numeric input using scanf. It is far, far easier to do it some other way.
You will notice a theme running through all three cases I listed: they all began with "You are reading input using scanf...". There's a certain inescapable conclusion here. See this other question: What can I use for input conversion instead of scanf?
Now, I realize I still haven't answered the question you actually asked. When people ask, "How do I do X?", it can be really frustrating when all the answers are, "You shouldn't want to do X." If you really, really want to flush input, then besides the other answers people have given you here, two other good questions full of relevant answers are:
How to properly flush stdin in fgets loop
Using fflush(stdin)
I am surprised nobody mentioned this:
scanf("%*[^\n]");
How can I flush or clear the stdin input buffer in C?
The fflush() reference on the cppreference.com community wiki states (emphasis added):
For input streams (and for update streams on which the last operation was input), the behavior is undefined.
So, do not use fflush() on stdin.
If your goal of "flushing" stdin is to remove all chars sitting in the stdin buffer, then the best way to do it is manually with either getchar() or getc(stdin) (the same thing), or perhaps with read() (using stdin as the first argument) if using POSIX or Linux.
The most-upvoted answers here and here both do this with:
int c;
while ((c = getchar()) != '\n' && c != EOF);
I think a clearer (more-readable) way is to do it like this. My comments, of course, make my approach look much longer than it is:
/// Clear the stdin input stream by reading and discarding all incoming chars up
/// to and including the Enter key's newline ('\n') char. Once we hit the
/// newline char, stop calling `getc()`, as calls to `getc()` beyond that will
/// block again, waiting for more user input.
/// - I copied this function
/// from "eRCaGuy_hello_world/c/read_stdin_getc_until_only_enter_key.c".
void clear_stdin()
{
// keep reading 1 more char as long as the end of the stream, indicated by
// `EOF` (end of file), and the end of the line, indicated by the newline
// char inserted into the stream when you pressed Enter, have NOT been
// reached
while (true)
{
int c = getc(stdin);
if (c == EOF || c == '\n')
{
break;
}
}
}
I use this function in my two files here, for instance. See the context in these files for when clearing stdin might be most-useful:
array_2d_fill_from_user_input_scanf_and_getc.c
read_stdin_getc_until_only_enter_key.c
Note to self: I originally posted this answer here, but have since deleted that answer to leave this one as my only answer instead.
I encounter a problem trying to implement the solution
while ((c = getchar()) != '\n' && c != EOF) { }
I post a little adjustment 'Code B' for anyone who maybe have the same problem.
The problem was that the program kept me catching the '\n' character, independently from the enter character, here is the code that gave me the problem.
Code A
int y;
printf("\nGive any alphabetic character in lowercase: ");
while( (y = getchar()) != '\n' && y != EOF){
continue;
}
printf("\n%c\n", toupper(y));
and the adjustment was to 'catch' the (n-1) character just before the conditional in the while loop be evaluated, here is the code:
Code B
int y, x;
printf("\nGive any alphabetic character in lowercase: ");
while( (y = getchar()) != '\n' && y != EOF){
x = y;
}
printf("\n%c\n", toupper(x));
The possible explanation is that for the while loop to break, it has to assign the value '\n' to the variable y, so it will be the last assigned value.
If I missed something with the explanation, code A or code B please tell me, I’m barely new in c.
hope it helps someone
Try this:
stdin->_IO_read_ptr = stdin->_IO_read_end;
unsigned char a=0;
if(kbhit()){
a=getch();
while(kbhit())
getch();
}
cout<<hex<<(static_cast<unsigned int:->(a) & 0xFF)<<endl;
-or-
use maybe use _getch_nolock() ..???
Another solution not mentioned yet is to use:
rewind(stdin);
In brief. Putting the line...
while ((c = getchar()) != '\n') ;
...before the line reading the input is the only guaranteed method.
It uses only core C features ("conventional core of C language" as per K&R) which are guaranteed to work with all compilers in all circumstances.
In reality you may choose to add a prompt asking a user to hit ENTER to continue (or, optionally, hit Ctrl-D or any other button to finish or to perform other code):
printf("\nPress ENTER to continue, press CTRL-D when finished\n");
while ((c = getchar()) != '\n') {
if (c == EOF) {
printf("\nEnd of program, exiting now...\n");
return 0;
}
...
}
There is still a problem. A user can hit ENTER many times. This can be worked around by adding an input check to your input line:
while ((ch2 = getchar()) < 'a' || ch1 > 'Z') ;
Combination of the above two methods theoretically should be bulletproof.
In all other aspects the answer by #jamesdlin is the most comprehensive.
Quick solution is to add a 2nd scanf so that it forces ch2 to temporarily eat the carriage return. Doesn't do any checking so it assumes the user will play nice. Not exactly clearing the input buffer but it works just fine.
int main(int argc, char *argv[])
{
char ch1, ch2;
printf("Input the first character:"); // Line 1
scanf("%c", &ch1);
scanf("%c", &ch2); // This eats '\n' and allows you to enter your input
printf("Input the second character:"); // Line 2
ch2 = getchar();
printf("ch1=%c, ASCII code = %d\n", ch1, ch1);
printf("ch2=%c, ASCII code = %d\n", ch2, ch2);
system("PAUSE");
return 0;
}
I have written a function (and tested it too) which gets input from stdin and discards extra input (characters). This function is called get_input_from_stdin_and_discard_extra_characters(char *str, int size) and it reads at max "size - 1" characters and appends a '\0' at the end.
The code is below:
/* read at most size - 1 characters. */
char *get_input_from_stdin_and_discard_extra_characters(char *str, int size)
{
char c = 0;
int num_chars_to_read = size - 1;
int i = 0;
if (!str)
return NULL;
if (num_chars_to_read <= 0)
return NULL;
for (i = 0; i < num_chars_to_read; i++) {
c = getchar();
if ((c == '\n') || (c == EOF)) {
str[i] = 0;
return str;
}
str[i] = c;
} // end of for loop
str[i] = 0;
// discard rest of input
while ((c = getchar()) && (c != '\n') && (c != EOF));
return str;
} // end of get_input_from_stdin_and_discard_extra_characters
Just for completeness, in your case if you actually want to use scanf which there are plenty of reasons not to, I would add a space in front of the format specifier, telling scanf to ignore all whitespace in front of the character:
scanf(" %c", &ch1);
See more details here: https://en.cppreference.com/w/c/io/fscanf#Notes
Short, portable and declared in stdio.h
stdin = freopen(NULL,"r",stdin);
Doesn't get hung in an infinite loop when there is nothing on stdin to flush like the following well know line:
while ((c = getchar()) != '\n' && c != EOF) { }
A little expensive so don't use it in a program that needs to repeatedly clear the buffer.
Stole from a coworker :)
Related
I have the following program:
int main(int argc, char *argv[])
{
char ch1, ch2;
printf("Input the first character:"); // Line 1
scanf("%c", &ch1);
printf("Input the second character:"); // Line 2
ch2 = getchar();
printf("ch1=%c, ASCII code = %d\n", ch1, ch1);
printf("ch2=%c, ASCII code = %d\n", ch2, ch2);
system("PAUSE");
return 0;
}
As the author of the above code have explained:
The program will not work properly because at Line 1, when the user presses Enter, it will leave in the input buffer 2 character: Enter key (ASCII code 13) and \n (ASCII code 10). Therefore, at Line 2, it will read the \n and will not wait for the user to enter a character.
OK, I got this. But my first question is: Why the second getchar() (ch2 = getchar();) does not read the Enter key (13), rather than \n character?
Next, the author proposed 2 ways to solve such probrems:
use fflush()
write a function like this:
void
clear (void)
{
while ( getchar() != '\n' );
}
This code worked actually. But I cannot explain myself how it works? Because in the while statement, we use getchar() != '\n', that means read any single character except '\n'? if so, in the input buffer still remains the '\n' character?
The program will not work properly because at Line 1, when the user presses Enter, it will leave in the input buffer 2 character: Enter key (ASCII code 13) and \n (ASCII code 10). Therefore, at Line 2, it will read the \n and will not wait for the user to enter a character.
The behavior you see at line 2 is correct, but that's not quite the correct explanation. With text-mode streams, it doesn't matter what line-endings your platform uses (whether carriage return (0x0D) + linefeed (0x0A), a bare CR, or a bare LF). The C runtime library will take care of that for you: your program will see just '\n' for newlines.
If you typed a character and pressed enter, then that input character would be read by line 1, and then '\n' would be read by line 2. See I'm using scanf %c to read a Y/N response, but later input gets skipped. from the comp.lang.c FAQ.
As for the proposed solutions, see (again from the comp.lang.c FAQ):
How can I flush pending input so that a user's typeahead isn't read at the next prompt? Will fflush(stdin) work?
If fflush won't work, what can I use to flush input?
which basically state that the only portable approach is to do:
int c;
while ((c = getchar()) != '\n' && c != EOF) { }
Your getchar() != '\n' loop works because once you call getchar(), the returned character already has been removed from the input stream.
Also, I feel obligated to discourage you from using scanf entirely: Why does everyone say not to use scanf? What should I use instead?
You can do it (also) this way:
fseek(stdin,0,SEEK_END);
A portable way to clear up to the end of a line that you've already tried to read partially is:
int c;
while ( (c = getchar()) != '\n' && c != EOF ) { }
This reads and discards characters until it gets \n which signals the end of the file. It also checks against EOF in case the input stream gets closed before the end of the line. The type of c must be int (or larger) in order to be able to hold the value EOF.
There is no portable way to find out if there are any more lines after the current line (if there aren't, then getchar will block for input).
The lines:
int ch;
while ((ch = getchar()) != '\n' && ch != EOF)
;
doesn't read only the characters before the linefeed ('\n'). It reads all the characters in the stream (and discards them) up to and including the next linefeed (or EOF is encountered). For the test to be true, it has to read the linefeed first; so when the loop stops, the linefeed was the last character read, but it has been read.
As for why it reads a linefeed instead of a carriage return, that's because the system has translated the return to a linefeed. When enter is pressed, that signals the end of the line... but the stream contains a line feed instead since that's the normal end-of-line marker for the system. That might be platform dependent.
Also, using fflush() on an input stream doesn't work on all platforms; for example it doesn't generally work on Linux.
But I cannot explain myself how it works? Because in the while statement, we use getchar() != '\n', that means read any single character except '\n'?? if so, in the input buffer still remains the '\n' character???
Am I misunderstanding something??
The thing you may not realize is that the comparison happens after getchar() removes the character from the input buffer. So when you reach the '\n', it is consumed and then you break out of the loop.
you can try
scanf("%c%*c", &ch1);
where %*c accepts and ignores the newline
one more method
instead of fflush(stdin) which invokes undefined behaviour you can write
while((getchar())!='\n');
don't forget the semicolon after while loop
scanf is a strange function, and there's a classic line from the movie WarGames that's relevant: "The only winning move is not to play".
If you find yourself needing to "flush input", you have already lost. The winning move is not to search desperately for some magic way to flush the nettlesome input: instead, what you need to do is to do input in some different (better) way, that doesn't involve leaving unread input on the input stream, and having it sit there and cause problems, such that you have to try to flush it instead.
There are basically three cases:
You are reading input using scanf, and it is leaving the user's newline on the input stream, and that stray newline is wrongly getting read by a later call to getchar or fgets. (This is the case you were initially asking about.)
You are reading input using scanf, and it is leaving the user's newline on the input stream, and that stray newline is wrongly getting read by a later call to scanf("%c").
You are reading numeric input using scanf, and the user is typing non-numeric text, and the non-numeric text is getting left on the input stream, meaning that the next call to scanf fails on it also.
In all three cases, it may seem like the right thing to do is to "flush" the offending input. And you can try, but it's cumbersome at best and impossible at worst. In the end I believe that trying to flush input is the wrong approach, and that there are better ways, depending on which case you were worried about:
In case 1, the better solution is, do not mix calls to scanf with other input functions. Either do all your input with scanf, or do all your input with getchar and/or fgets. To do all your input with scanf, you can replace calls to getchar with scanf("%c") — but see point 2. Theoretically you can replace calls to fgets with scanf("%[^\n]%*c"), although this has all sorts of further problems and I do not recommend it. To do all your input with fgets even though you wanted/needed some of scanf's parsing, you can read lines using fgets and then parse them after the fact using sscanf.
In case 2, the better solution is, never use scanf("%c"). Use scanf(" %c") instead. The magic extra space makes all the difference. (There's a long explanation of what that extra space does and why it helps, but it's beyond the scope of this answer.)
And in case 3, I'm afraid that there simply is no good solution. scanf has many problems, and one of its many problems is that its error handling is terrible. If you want to write a simple program that reads numeric input, and if you can assume that the user will always type proper numeric input when prompted to, then scanf("%d") can be an adequate — barely adequate — input method. But perhaps your goal is to do better. Perhaps you'd like to prompt the user for some numeric input, and check that the user did in fact enter numeric input, and if not, print an error message and ask the user to try again. In that case, I believe that for all intents and purposes you cannot meet this goal based around scanf. You can try, but it's like putting a onesie on a squirming baby: after getting both legs and one arm in, while you're trying to get the second arm in, one leg will have wriggled out. It is just far too much work to try to read and validate possibly-incorrect numeric input using scanf. It is far, far easier to do it some other way.
You will notice a theme running through all three cases I listed: they all began with "You are reading input using scanf...". There's a certain inescapable conclusion here. See this other question: What can I use for input conversion instead of scanf?
Now, I realize I still haven't answered the question you actually asked. When people ask, "How do I do X?", it can be really frustrating when all the answers are, "You shouldn't want to do X." If you really, really want to flush input, then besides the other answers people have given you here, two other good questions full of relevant answers are:
How to properly flush stdin in fgets loop
Using fflush(stdin)
I am surprised nobody mentioned this:
scanf("%*[^\n]");
How can I flush or clear the stdin input buffer in C?
The fflush() reference on the cppreference.com community wiki states (emphasis added):
For input streams (and for update streams on which the last operation was input), the behavior is undefined.
So, do not use fflush() on stdin.
If your goal of "flushing" stdin is to remove all chars sitting in the stdin buffer, then the best way to do it is manually with either getchar() or getc(stdin) (the same thing), or perhaps with read() (using stdin as the first argument) if using POSIX or Linux.
The most-upvoted answers here and here both do this with:
int c;
while ((c = getchar()) != '\n' && c != EOF);
I think a clearer (more-readable) way is to do it like this. My comments, of course, make my approach look much longer than it is:
/// Clear the stdin input stream by reading and discarding all incoming chars up
/// to and including the Enter key's newline ('\n') char. Once we hit the
/// newline char, stop calling `getc()`, as calls to `getc()` beyond that will
/// block again, waiting for more user input.
/// - I copied this function
/// from "eRCaGuy_hello_world/c/read_stdin_getc_until_only_enter_key.c".
void clear_stdin()
{
// keep reading 1 more char as long as the end of the stream, indicated by
// `EOF` (end of file), and the end of the line, indicated by the newline
// char inserted into the stream when you pressed Enter, have NOT been
// reached
while (true)
{
int c = getc(stdin);
if (c == EOF || c == '\n')
{
break;
}
}
}
I use this function in my two files here, for instance. See the context in these files for when clearing stdin might be most-useful:
array_2d_fill_from_user_input_scanf_and_getc.c
read_stdin_getc_until_only_enter_key.c
Note to self: I originally posted this answer here, but have since deleted that answer to leave this one as my only answer instead.
I encounter a problem trying to implement the solution
while ((c = getchar()) != '\n' && c != EOF) { }
I post a little adjustment 'Code B' for anyone who maybe have the same problem.
The problem was that the program kept me catching the '\n' character, independently from the enter character, here is the code that gave me the problem.
Code A
int y;
printf("\nGive any alphabetic character in lowercase: ");
while( (y = getchar()) != '\n' && y != EOF){
continue;
}
printf("\n%c\n", toupper(y));
and the adjustment was to 'catch' the (n-1) character just before the conditional in the while loop be evaluated, here is the code:
Code B
int y, x;
printf("\nGive any alphabetic character in lowercase: ");
while( (y = getchar()) != '\n' && y != EOF){
x = y;
}
printf("\n%c\n", toupper(x));
The possible explanation is that for the while loop to break, it has to assign the value '\n' to the variable y, so it will be the last assigned value.
If I missed something with the explanation, code A or code B please tell me, I’m barely new in c.
hope it helps someone
Try this:
stdin->_IO_read_ptr = stdin->_IO_read_end;
unsigned char a=0;
if(kbhit()){
a=getch();
while(kbhit())
getch();
}
cout<<hex<<(static_cast<unsigned int:->(a) & 0xFF)<<endl;
-or-
use maybe use _getch_nolock() ..???
Another solution not mentioned yet is to use:
rewind(stdin);
In brief. Putting the line...
while ((c = getchar()) != '\n') ;
...before the line reading the input is the only guaranteed method.
It uses only core C features ("conventional core of C language" as per K&R) which are guaranteed to work with all compilers in all circumstances.
In reality you may choose to add a prompt asking a user to hit ENTER to continue (or, optionally, hit Ctrl-D or any other button to finish or to perform other code):
printf("\nPress ENTER to continue, press CTRL-D when finished\n");
while ((c = getchar()) != '\n') {
if (c == EOF) {
printf("\nEnd of program, exiting now...\n");
return 0;
}
...
}
There is still a problem. A user can hit ENTER many times. This can be worked around by adding an input check to your input line:
while ((ch2 = getchar()) < 'a' || ch1 > 'Z') ;
Combination of the above two methods theoretically should be bulletproof.
In all other aspects the answer by #jamesdlin is the most comprehensive.
Quick solution is to add a 2nd scanf so that it forces ch2 to temporarily eat the carriage return. Doesn't do any checking so it assumes the user will play nice. Not exactly clearing the input buffer but it works just fine.
int main(int argc, char *argv[])
{
char ch1, ch2;
printf("Input the first character:"); // Line 1
scanf("%c", &ch1);
scanf("%c", &ch2); // This eats '\n' and allows you to enter your input
printf("Input the second character:"); // Line 2
ch2 = getchar();
printf("ch1=%c, ASCII code = %d\n", ch1, ch1);
printf("ch2=%c, ASCII code = %d\n", ch2, ch2);
system("PAUSE");
return 0;
}
I have written a function (and tested it too) which gets input from stdin and discards extra input (characters). This function is called get_input_from_stdin_and_discard_extra_characters(char *str, int size) and it reads at max "size - 1" characters and appends a '\0' at the end.
The code is below:
/* read at most size - 1 characters. */
char *get_input_from_stdin_and_discard_extra_characters(char *str, int size)
{
char c = 0;
int num_chars_to_read = size - 1;
int i = 0;
if (!str)
return NULL;
if (num_chars_to_read <= 0)
return NULL;
for (i = 0; i < num_chars_to_read; i++) {
c = getchar();
if ((c == '\n') || (c == EOF)) {
str[i] = 0;
return str;
}
str[i] = c;
} // end of for loop
str[i] = 0;
// discard rest of input
while ((c = getchar()) && (c != '\n') && (c != EOF));
return str;
} // end of get_input_from_stdin_and_discard_extra_characters
Just for completeness, in your case if you actually want to use scanf which there are plenty of reasons not to, I would add a space in front of the format specifier, telling scanf to ignore all whitespace in front of the character:
scanf(" %c", &ch1);
See more details here: https://en.cppreference.com/w/c/io/fscanf#Notes
Short, portable and declared in stdio.h
stdin = freopen(NULL,"r",stdin);
Doesn't get hung in an infinite loop when there is nothing on stdin to flush like the following well know line:
while ((c = getchar()) != '\n' && c != EOF) { }
A little expensive so don't use it in a program that needs to repeatedly clear the buffer.
Stole from a coworker :)
I have the following program:
int main(int argc, char *argv[])
{
char ch1, ch2;
printf("Input the first character:"); // Line 1
scanf("%c", &ch1);
printf("Input the second character:"); // Line 2
ch2 = getchar();
printf("ch1=%c, ASCII code = %d\n", ch1, ch1);
printf("ch2=%c, ASCII code = %d\n", ch2, ch2);
system("PAUSE");
return 0;
}
As the author of the above code have explained:
The program will not work properly because at Line 1, when the user presses Enter, it will leave in the input buffer 2 character: Enter key (ASCII code 13) and \n (ASCII code 10). Therefore, at Line 2, it will read the \n and will not wait for the user to enter a character.
OK, I got this. But my first question is: Why the second getchar() (ch2 = getchar();) does not read the Enter key (13), rather than \n character?
Next, the author proposed 2 ways to solve such probrems:
use fflush()
write a function like this:
void
clear (void)
{
while ( getchar() != '\n' );
}
This code worked actually. But I cannot explain myself how it works? Because in the while statement, we use getchar() != '\n', that means read any single character except '\n'? if so, in the input buffer still remains the '\n' character?
The program will not work properly because at Line 1, when the user presses Enter, it will leave in the input buffer 2 character: Enter key (ASCII code 13) and \n (ASCII code 10). Therefore, at Line 2, it will read the \n and will not wait for the user to enter a character.
The behavior you see at line 2 is correct, but that's not quite the correct explanation. With text-mode streams, it doesn't matter what line-endings your platform uses (whether carriage return (0x0D) + linefeed (0x0A), a bare CR, or a bare LF). The C runtime library will take care of that for you: your program will see just '\n' for newlines.
If you typed a character and pressed enter, then that input character would be read by line 1, and then '\n' would be read by line 2. See I'm using scanf %c to read a Y/N response, but later input gets skipped. from the comp.lang.c FAQ.
As for the proposed solutions, see (again from the comp.lang.c FAQ):
How can I flush pending input so that a user's typeahead isn't read at the next prompt? Will fflush(stdin) work?
If fflush won't work, what can I use to flush input?
which basically state that the only portable approach is to do:
int c;
while ((c = getchar()) != '\n' && c != EOF) { }
Your getchar() != '\n' loop works because once you call getchar(), the returned character already has been removed from the input stream.
Also, I feel obligated to discourage you from using scanf entirely: Why does everyone say not to use scanf? What should I use instead?
You can do it (also) this way:
fseek(stdin,0,SEEK_END);
A portable way to clear up to the end of a line that you've already tried to read partially is:
int c;
while ( (c = getchar()) != '\n' && c != EOF ) { }
This reads and discards characters until it gets \n which signals the end of the file. It also checks against EOF in case the input stream gets closed before the end of the line. The type of c must be int (or larger) in order to be able to hold the value EOF.
There is no portable way to find out if there are any more lines after the current line (if there aren't, then getchar will block for input).
The lines:
int ch;
while ((ch = getchar()) != '\n' && ch != EOF)
;
doesn't read only the characters before the linefeed ('\n'). It reads all the characters in the stream (and discards them) up to and including the next linefeed (or EOF is encountered). For the test to be true, it has to read the linefeed first; so when the loop stops, the linefeed was the last character read, but it has been read.
As for why it reads a linefeed instead of a carriage return, that's because the system has translated the return to a linefeed. When enter is pressed, that signals the end of the line... but the stream contains a line feed instead since that's the normal end-of-line marker for the system. That might be platform dependent.
Also, using fflush() on an input stream doesn't work on all platforms; for example it doesn't generally work on Linux.
But I cannot explain myself how it works? Because in the while statement, we use getchar() != '\n', that means read any single character except '\n'?? if so, in the input buffer still remains the '\n' character???
Am I misunderstanding something??
The thing you may not realize is that the comparison happens after getchar() removes the character from the input buffer. So when you reach the '\n', it is consumed and then you break out of the loop.
you can try
scanf("%c%*c", &ch1);
where %*c accepts and ignores the newline
one more method
instead of fflush(stdin) which invokes undefined behaviour you can write
while((getchar())!='\n');
don't forget the semicolon after while loop
scanf is a strange function, and there's a classic line from the movie WarGames that's relevant: "The only winning move is not to play".
If you find yourself needing to "flush input", you have already lost. The winning move is not to search desperately for some magic way to flush the nettlesome input: instead, what you need to do is to do input in some different (better) way, that doesn't involve leaving unread input on the input stream, and having it sit there and cause problems, such that you have to try to flush it instead.
There are basically three cases:
You are reading input using scanf, and it is leaving the user's newline on the input stream, and that stray newline is wrongly getting read by a later call to getchar or fgets. (This is the case you were initially asking about.)
You are reading input using scanf, and it is leaving the user's newline on the input stream, and that stray newline is wrongly getting read by a later call to scanf("%c").
You are reading numeric input using scanf, and the user is typing non-numeric text, and the non-numeric text is getting left on the input stream, meaning that the next call to scanf fails on it also.
In all three cases, it may seem like the right thing to do is to "flush" the offending input. And you can try, but it's cumbersome at best and impossible at worst. In the end I believe that trying to flush input is the wrong approach, and that there are better ways, depending on which case you were worried about:
In case 1, the better solution is, do not mix calls to scanf with other input functions. Either do all your input with scanf, or do all your input with getchar and/or fgets. To do all your input with scanf, you can replace calls to getchar with scanf("%c") — but see point 2. Theoretically you can replace calls to fgets with scanf("%[^\n]%*c"), although this has all sorts of further problems and I do not recommend it. To do all your input with fgets even though you wanted/needed some of scanf's parsing, you can read lines using fgets and then parse them after the fact using sscanf.
In case 2, the better solution is, never use scanf("%c"). Use scanf(" %c") instead. The magic extra space makes all the difference. (There's a long explanation of what that extra space does and why it helps, but it's beyond the scope of this answer.)
And in case 3, I'm afraid that there simply is no good solution. scanf has many problems, and one of its many problems is that its error handling is terrible. If you want to write a simple program that reads numeric input, and if you can assume that the user will always type proper numeric input when prompted to, then scanf("%d") can be an adequate — barely adequate — input method. But perhaps your goal is to do better. Perhaps you'd like to prompt the user for some numeric input, and check that the user did in fact enter numeric input, and if not, print an error message and ask the user to try again. In that case, I believe that for all intents and purposes you cannot meet this goal based around scanf. You can try, but it's like putting a onesie on a squirming baby: after getting both legs and one arm in, while you're trying to get the second arm in, one leg will have wriggled out. It is just far too much work to try to read and validate possibly-incorrect numeric input using scanf. It is far, far easier to do it some other way.
You will notice a theme running through all three cases I listed: they all began with "You are reading input using scanf...". There's a certain inescapable conclusion here. See this other question: What can I use for input conversion instead of scanf?
Now, I realize I still haven't answered the question you actually asked. When people ask, "How do I do X?", it can be really frustrating when all the answers are, "You shouldn't want to do X." If you really, really want to flush input, then besides the other answers people have given you here, two other good questions full of relevant answers are:
How to properly flush stdin in fgets loop
Using fflush(stdin)
I am surprised nobody mentioned this:
scanf("%*[^\n]");
How can I flush or clear the stdin input buffer in C?
The fflush() reference on the cppreference.com community wiki states (emphasis added):
For input streams (and for update streams on which the last operation was input), the behavior is undefined.
So, do not use fflush() on stdin.
If your goal of "flushing" stdin is to remove all chars sitting in the stdin buffer, then the best way to do it is manually with either getchar() or getc(stdin) (the same thing), or perhaps with read() (using stdin as the first argument) if using POSIX or Linux.
The most-upvoted answers here and here both do this with:
int c;
while ((c = getchar()) != '\n' && c != EOF);
I think a clearer (more-readable) way is to do it like this. My comments, of course, make my approach look much longer than it is:
/// Clear the stdin input stream by reading and discarding all incoming chars up
/// to and including the Enter key's newline ('\n') char. Once we hit the
/// newline char, stop calling `getc()`, as calls to `getc()` beyond that will
/// block again, waiting for more user input.
/// - I copied this function
/// from "eRCaGuy_hello_world/c/read_stdin_getc_until_only_enter_key.c".
void clear_stdin()
{
// keep reading 1 more char as long as the end of the stream, indicated by
// `EOF` (end of file), and the end of the line, indicated by the newline
// char inserted into the stream when you pressed Enter, have NOT been
// reached
while (true)
{
int c = getc(stdin);
if (c == EOF || c == '\n')
{
break;
}
}
}
I use this function in my two files here, for instance. See the context in these files for when clearing stdin might be most-useful:
array_2d_fill_from_user_input_scanf_and_getc.c
read_stdin_getc_until_only_enter_key.c
Note to self: I originally posted this answer here, but have since deleted that answer to leave this one as my only answer instead.
I encounter a problem trying to implement the solution
while ((c = getchar()) != '\n' && c != EOF) { }
I post a little adjustment 'Code B' for anyone who maybe have the same problem.
The problem was that the program kept me catching the '\n' character, independently from the enter character, here is the code that gave me the problem.
Code A
int y;
printf("\nGive any alphabetic character in lowercase: ");
while( (y = getchar()) != '\n' && y != EOF){
continue;
}
printf("\n%c\n", toupper(y));
and the adjustment was to 'catch' the (n-1) character just before the conditional in the while loop be evaluated, here is the code:
Code B
int y, x;
printf("\nGive any alphabetic character in lowercase: ");
while( (y = getchar()) != '\n' && y != EOF){
x = y;
}
printf("\n%c\n", toupper(x));
The possible explanation is that for the while loop to break, it has to assign the value '\n' to the variable y, so it will be the last assigned value.
If I missed something with the explanation, code A or code B please tell me, I’m barely new in c.
hope it helps someone
Try this:
stdin->_IO_read_ptr = stdin->_IO_read_end;
unsigned char a=0;
if(kbhit()){
a=getch();
while(kbhit())
getch();
}
cout<<hex<<(static_cast<unsigned int:->(a) & 0xFF)<<endl;
-or-
use maybe use _getch_nolock() ..???
Another solution not mentioned yet is to use:
rewind(stdin);
In brief. Putting the line...
while ((c = getchar()) != '\n') ;
...before the line reading the input is the only guaranteed method.
It uses only core C features ("conventional core of C language" as per K&R) which are guaranteed to work with all compilers in all circumstances.
In reality you may choose to add a prompt asking a user to hit ENTER to continue (or, optionally, hit Ctrl-D or any other button to finish or to perform other code):
printf("\nPress ENTER to continue, press CTRL-D when finished\n");
while ((c = getchar()) != '\n') {
if (c == EOF) {
printf("\nEnd of program, exiting now...\n");
return 0;
}
...
}
There is still a problem. A user can hit ENTER many times. This can be worked around by adding an input check to your input line:
while ((ch2 = getchar()) < 'a' || ch1 > 'Z') ;
Combination of the above two methods theoretically should be bulletproof.
In all other aspects the answer by #jamesdlin is the most comprehensive.
Quick solution is to add a 2nd scanf so that it forces ch2 to temporarily eat the carriage return. Doesn't do any checking so it assumes the user will play nice. Not exactly clearing the input buffer but it works just fine.
int main(int argc, char *argv[])
{
char ch1, ch2;
printf("Input the first character:"); // Line 1
scanf("%c", &ch1);
scanf("%c", &ch2); // This eats '\n' and allows you to enter your input
printf("Input the second character:"); // Line 2
ch2 = getchar();
printf("ch1=%c, ASCII code = %d\n", ch1, ch1);
printf("ch2=%c, ASCII code = %d\n", ch2, ch2);
system("PAUSE");
return 0;
}
I have written a function (and tested it too) which gets input from stdin and discards extra input (characters). This function is called get_input_from_stdin_and_discard_extra_characters(char *str, int size) and it reads at max "size - 1" characters and appends a '\0' at the end.
The code is below:
/* read at most size - 1 characters. */
char *get_input_from_stdin_and_discard_extra_characters(char *str, int size)
{
char c = 0;
int num_chars_to_read = size - 1;
int i = 0;
if (!str)
return NULL;
if (num_chars_to_read <= 0)
return NULL;
for (i = 0; i < num_chars_to_read; i++) {
c = getchar();
if ((c == '\n') || (c == EOF)) {
str[i] = 0;
return str;
}
str[i] = c;
} // end of for loop
str[i] = 0;
// discard rest of input
while ((c = getchar()) && (c != '\n') && (c != EOF));
return str;
} // end of get_input_from_stdin_and_discard_extra_characters
Just for completeness, in your case if you actually want to use scanf which there are plenty of reasons not to, I would add a space in front of the format specifier, telling scanf to ignore all whitespace in front of the character:
scanf(" %c", &ch1);
See more details here: https://en.cppreference.com/w/c/io/fscanf#Notes
Short, portable and declared in stdio.h
stdin = freopen(NULL,"r",stdin);
Doesn't get hung in an infinite loop when there is nothing on stdin to flush like the following well know line:
while ((c = getchar()) != '\n' && c != EOF) { }
A little expensive so don't use it in a program that needs to repeatedly clear the buffer.
Stole from a coworker :)
I'm working in a Linux terminal and have I'm writing a program that requires the user to hit CTRL-D at the end of their input to signify the end of input. The program hangs on the while loop waiting for another input to scan even though I'm pressing the CTRL-D button. The weirdest part is that if I press it enough times, it will register and store the EOF keystroke to my variable, and finish the program correctly.
My code snippet:
char c;
scanf("%c",&c);
while(index<size && c!=EOF){
A[index] = c;
index++;
scanf("%c",&c);
}
I stepped through my program in gdb and every time I've entered my input and it has scanned it all, it waits for more input, at which point I use the CTRL-D keystroke, but it doesn't even register it. I haven't found anything in researching this issue, and I'm confused as to why it works sometimes (if I press it enough times), and not others. What is going on?
scanf, unlike fgetc, never sets it parameters to EOF. In case scanf is unable to read its parameter(s) due to eof, it simply leaves them unchanged. So the check c!=EOF is obsolete. You may check for feof(stdin). Alternatively, you may check the return code of scanf:
int rc = scanf("%c", &c);
It returns the number of parameters it succesfully reads, or sometimes it returns EOF.
I was able to implement the desired behavior using fgetc()
char c = fgetc(stdin);
while(index<size && c!=EOF){
A[index] = c;
index++;
fgetc(stdin);
}
From the man page of fgetc: "fgetc() reads the next character from stream and returns it as an unsigned char cast to an int, or EOF on end of file or error." I guess scanf fails to properly recognize EOF. (see below)
Alternatively, use the feof function provided by stdio.h:
while(index < size){
c = fgetc(stdin);
if(feof(stdin)) break;
}
It's generally recommended to use the fgets() family of functions for I/O-Operations, since they are (mostly) safer than scanf.
Man pages with further information: fgetc, feof, scanf.
EDIT: After posting my answer and reading the comments under the question: scanf() returns EOF (like fgetc) when encountering an end of file error. This means checking the return value of scanf will fix the problem, e.g.
while(index < size && scanf("%c", &c) != EOF){
//do stuff
}
I have to write a program in C that handles the newline as part of a string. I need a way of handling the newline char such that if it is encountered, it doesn't necessarily terminate the input. So far I've been using fgets() but that stops as soon as it reaches a '\n' char. Is there a good function for processing the input from the console that doesn't necessarily end at the newline character?
To clarify:
I need a method that doesn't terminate at the newline char because in this particular exercise when the newline char is encountered it's replaced with a space char.
fgets gets a line from a stream. A line is defined as ending with a newline, end-of-file or error, so you don't want that.
You probably want to use fgetc. Here's a code example of a c program file fgetc.c
#include <stdio.h>
int main (void) {
int c;
while ((c = fgetc(stdin)) != EOF) fputc(c, stdout);
}
compile like this:
cc fgetc.c -o fgetc
use like this (notice the newline character '\n'):
echo 'Hello, thar!\nOh, hai!' | ./fgetc
or like this:
cat fgetc.c | ./fgetc
Read the fgetc function manual to find out more: man fgetc
If I understand your question correctly you want to read from the standard input until user has finished typing ( which ain't be a newline of course ). This can be done by setting a flag like EOF while getting input. One way which I came out with is this:
#include <stdio.h>
int main(void)
{
char ch;
char str[100];
int i = 0;
setbuf (stdout,NULL);
while ( (ch = getchar()) != EOF)// user can input until the EOF which he or she enters to mark the end of his/her typing or more appropriately input.
{
str[i] = ch;// you can store all the input character by character in a char array
i++;
}
printf ("%s",str);// then you can print it at last as a whole
return 0;
}
BEGINNER's NOTE- EOF can vary from system to system so check it and enter the proper EOF for your system.
If you are simply reading blocks of information without the need for scanf(), then fread() may be what you are after. But on consoles you can read to the \n, notice the \n, then continue reading more if you decide that \n is not for you.
scanf works when used as directed. Specifically, it treats \n as white space.
Depending on how your application is coded (i.e. how buffers are defined), a \n prompts the system to flush the buffer and feed data into scanf. This should occur as a default without you having to do anything.
So the real question is, what kind of data or characters do you need from the console? In some cases scanf will remove white space and NOT pass blanks, tabs, new lines, into your program. However, scanf can be coded to NOT do this!
Define how data should be entered and I can guide you on how to code scanf.
I have the following program:
int main(int argc, char *argv[])
{
char ch1, ch2;
printf("Input the first character:"); // Line 1
scanf("%c", &ch1);
printf("Input the second character:"); // Line 2
ch2 = getchar();
printf("ch1=%c, ASCII code = %d\n", ch1, ch1);
printf("ch2=%c, ASCII code = %d\n", ch2, ch2);
system("PAUSE");
return 0;
}
As the author of the above code have explained:
The program will not work properly because at Line 1, when the user presses Enter, it will leave in the input buffer 2 character: Enter key (ASCII code 13) and \n (ASCII code 10). Therefore, at Line 2, it will read the \n and will not wait for the user to enter a character.
OK, I got this. But my first question is: Why the second getchar() (ch2 = getchar();) does not read the Enter key (13), rather than \n character?
Next, the author proposed 2 ways to solve such probrems:
use fflush()
write a function like this:
void
clear (void)
{
while ( getchar() != '\n' );
}
This code worked actually. But I cannot explain myself how it works? Because in the while statement, we use getchar() != '\n', that means read any single character except '\n'? if so, in the input buffer still remains the '\n' character?
The program will not work properly because at Line 1, when the user presses Enter, it will leave in the input buffer 2 character: Enter key (ASCII code 13) and \n (ASCII code 10). Therefore, at Line 2, it will read the \n and will not wait for the user to enter a character.
The behavior you see at line 2 is correct, but that's not quite the correct explanation. With text-mode streams, it doesn't matter what line-endings your platform uses (whether carriage return (0x0D) + linefeed (0x0A), a bare CR, or a bare LF). The C runtime library will take care of that for you: your program will see just '\n' for newlines.
If you typed a character and pressed enter, then that input character would be read by line 1, and then '\n' would be read by line 2. See I'm using scanf %c to read a Y/N response, but later input gets skipped. from the comp.lang.c FAQ.
As for the proposed solutions, see (again from the comp.lang.c FAQ):
How can I flush pending input so that a user's typeahead isn't read at the next prompt? Will fflush(stdin) work?
If fflush won't work, what can I use to flush input?
which basically state that the only portable approach is to do:
int c;
while ((c = getchar()) != '\n' && c != EOF) { }
Your getchar() != '\n' loop works because once you call getchar(), the returned character already has been removed from the input stream.
Also, I feel obligated to discourage you from using scanf entirely: Why does everyone say not to use scanf? What should I use instead?
You can do it (also) this way:
fseek(stdin,0,SEEK_END);
A portable way to clear up to the end of a line that you've already tried to read partially is:
int c;
while ( (c = getchar()) != '\n' && c != EOF ) { }
This reads and discards characters until it gets \n which signals the end of the file. It also checks against EOF in case the input stream gets closed before the end of the line. The type of c must be int (or larger) in order to be able to hold the value EOF.
There is no portable way to find out if there are any more lines after the current line (if there aren't, then getchar will block for input).
The lines:
int ch;
while ((ch = getchar()) != '\n' && ch != EOF)
;
doesn't read only the characters before the linefeed ('\n'). It reads all the characters in the stream (and discards them) up to and including the next linefeed (or EOF is encountered). For the test to be true, it has to read the linefeed first; so when the loop stops, the linefeed was the last character read, but it has been read.
As for why it reads a linefeed instead of a carriage return, that's because the system has translated the return to a linefeed. When enter is pressed, that signals the end of the line... but the stream contains a line feed instead since that's the normal end-of-line marker for the system. That might be platform dependent.
Also, using fflush() on an input stream doesn't work on all platforms; for example it doesn't generally work on Linux.
But I cannot explain myself how it works? Because in the while statement, we use getchar() != '\n', that means read any single character except '\n'?? if so, in the input buffer still remains the '\n' character???
Am I misunderstanding something??
The thing you may not realize is that the comparison happens after getchar() removes the character from the input buffer. So when you reach the '\n', it is consumed and then you break out of the loop.
you can try
scanf("%c%*c", &ch1);
where %*c accepts and ignores the newline
one more method
instead of fflush(stdin) which invokes undefined behaviour you can write
while((getchar())!='\n');
don't forget the semicolon after while loop
scanf is a strange function, and there's a classic line from the movie WarGames that's relevant: "The only winning move is not to play".
If you find yourself needing to "flush input", you have already lost. The winning move is not to search desperately for some magic way to flush the nettlesome input: instead, what you need to do is to do input in some different (better) way, that doesn't involve leaving unread input on the input stream, and having it sit there and cause problems, such that you have to try to flush it instead.
There are basically three cases:
You are reading input using scanf, and it is leaving the user's newline on the input stream, and that stray newline is wrongly getting read by a later call to getchar or fgets. (This is the case you were initially asking about.)
You are reading input using scanf, and it is leaving the user's newline on the input stream, and that stray newline is wrongly getting read by a later call to scanf("%c").
You are reading numeric input using scanf, and the user is typing non-numeric text, and the non-numeric text is getting left on the input stream, meaning that the next call to scanf fails on it also.
In all three cases, it may seem like the right thing to do is to "flush" the offending input. And you can try, but it's cumbersome at best and impossible at worst. In the end I believe that trying to flush input is the wrong approach, and that there are better ways, depending on which case you were worried about:
In case 1, the better solution is, do not mix calls to scanf with other input functions. Either do all your input with scanf, or do all your input with getchar and/or fgets. To do all your input with scanf, you can replace calls to getchar with scanf("%c") — but see point 2. Theoretically you can replace calls to fgets with scanf("%[^\n]%*c"), although this has all sorts of further problems and I do not recommend it. To do all your input with fgets even though you wanted/needed some of scanf's parsing, you can read lines using fgets and then parse them after the fact using sscanf.
In case 2, the better solution is, never use scanf("%c"). Use scanf(" %c") instead. The magic extra space makes all the difference. (There's a long explanation of what that extra space does and why it helps, but it's beyond the scope of this answer.)
And in case 3, I'm afraid that there simply is no good solution. scanf has many problems, and one of its many problems is that its error handling is terrible. If you want to write a simple program that reads numeric input, and if you can assume that the user will always type proper numeric input when prompted to, then scanf("%d") can be an adequate — barely adequate — input method. But perhaps your goal is to do better. Perhaps you'd like to prompt the user for some numeric input, and check that the user did in fact enter numeric input, and if not, print an error message and ask the user to try again. In that case, I believe that for all intents and purposes you cannot meet this goal based around scanf. You can try, but it's like putting a onesie on a squirming baby: after getting both legs and one arm in, while you're trying to get the second arm in, one leg will have wriggled out. It is just far too much work to try to read and validate possibly-incorrect numeric input using scanf. It is far, far easier to do it some other way.
You will notice a theme running through all three cases I listed: they all began with "You are reading input using scanf...". There's a certain inescapable conclusion here. See this other question: What can I use for input conversion instead of scanf?
Now, I realize I still haven't answered the question you actually asked. When people ask, "How do I do X?", it can be really frustrating when all the answers are, "You shouldn't want to do X." If you really, really want to flush input, then besides the other answers people have given you here, two other good questions full of relevant answers are:
How to properly flush stdin in fgets loop
Using fflush(stdin)
I am surprised nobody mentioned this:
scanf("%*[^\n]");
How can I flush or clear the stdin input buffer in C?
The fflush() reference on the cppreference.com community wiki states (emphasis added):
For input streams (and for update streams on which the last operation was input), the behavior is undefined.
So, do not use fflush() on stdin.
If your goal of "flushing" stdin is to remove all chars sitting in the stdin buffer, then the best way to do it is manually with either getchar() or getc(stdin) (the same thing), or perhaps with read() (using stdin as the first argument) if using POSIX or Linux.
The most-upvoted answers here and here both do this with:
int c;
while ((c = getchar()) != '\n' && c != EOF);
I think a clearer (more-readable) way is to do it like this. My comments, of course, make my approach look much longer than it is:
/// Clear the stdin input stream by reading and discarding all incoming chars up
/// to and including the Enter key's newline ('\n') char. Once we hit the
/// newline char, stop calling `getc()`, as calls to `getc()` beyond that will
/// block again, waiting for more user input.
/// - I copied this function
/// from "eRCaGuy_hello_world/c/read_stdin_getc_until_only_enter_key.c".
void clear_stdin()
{
// keep reading 1 more char as long as the end of the stream, indicated by
// `EOF` (end of file), and the end of the line, indicated by the newline
// char inserted into the stream when you pressed Enter, have NOT been
// reached
while (true)
{
int c = getc(stdin);
if (c == EOF || c == '\n')
{
break;
}
}
}
I use this function in my two files here, for instance. See the context in these files for when clearing stdin might be most-useful:
array_2d_fill_from_user_input_scanf_and_getc.c
read_stdin_getc_until_only_enter_key.c
Note to self: I originally posted this answer here, but have since deleted that answer to leave this one as my only answer instead.
I encounter a problem trying to implement the solution
while ((c = getchar()) != '\n' && c != EOF) { }
I post a little adjustment 'Code B' for anyone who maybe have the same problem.
The problem was that the program kept me catching the '\n' character, independently from the enter character, here is the code that gave me the problem.
Code A
int y;
printf("\nGive any alphabetic character in lowercase: ");
while( (y = getchar()) != '\n' && y != EOF){
continue;
}
printf("\n%c\n", toupper(y));
and the adjustment was to 'catch' the (n-1) character just before the conditional in the while loop be evaluated, here is the code:
Code B
int y, x;
printf("\nGive any alphabetic character in lowercase: ");
while( (y = getchar()) != '\n' && y != EOF){
x = y;
}
printf("\n%c\n", toupper(x));
The possible explanation is that for the while loop to break, it has to assign the value '\n' to the variable y, so it will be the last assigned value.
If I missed something with the explanation, code A or code B please tell me, I’m barely new in c.
hope it helps someone
Try this:
stdin->_IO_read_ptr = stdin->_IO_read_end;
unsigned char a=0;
if(kbhit()){
a=getch();
while(kbhit())
getch();
}
cout<<hex<<(static_cast<unsigned int:->(a) & 0xFF)<<endl;
-or-
use maybe use _getch_nolock() ..???
Another solution not mentioned yet is to use:
rewind(stdin);
In brief. Putting the line...
while ((c = getchar()) != '\n') ;
...before the line reading the input is the only guaranteed method.
It uses only core C features ("conventional core of C language" as per K&R) which are guaranteed to work with all compilers in all circumstances.
In reality you may choose to add a prompt asking a user to hit ENTER to continue (or, optionally, hit Ctrl-D or any other button to finish or to perform other code):
printf("\nPress ENTER to continue, press CTRL-D when finished\n");
while ((c = getchar()) != '\n') {
if (c == EOF) {
printf("\nEnd of program, exiting now...\n");
return 0;
}
...
}
There is still a problem. A user can hit ENTER many times. This can be worked around by adding an input check to your input line:
while ((ch2 = getchar()) < 'a' || ch1 > 'Z') ;
Combination of the above two methods theoretically should be bulletproof.
In all other aspects the answer by #jamesdlin is the most comprehensive.
Quick solution is to add a 2nd scanf so that it forces ch2 to temporarily eat the carriage return. Doesn't do any checking so it assumes the user will play nice. Not exactly clearing the input buffer but it works just fine.
int main(int argc, char *argv[])
{
char ch1, ch2;
printf("Input the first character:"); // Line 1
scanf("%c", &ch1);
scanf("%c", &ch2); // This eats '\n' and allows you to enter your input
printf("Input the second character:"); // Line 2
ch2 = getchar();
printf("ch1=%c, ASCII code = %d\n", ch1, ch1);
printf("ch2=%c, ASCII code = %d\n", ch2, ch2);
system("PAUSE");
return 0;
}
I have written a function (and tested it too) which gets input from stdin and discards extra input (characters). This function is called get_input_from_stdin_and_discard_extra_characters(char *str, int size) and it reads at max "size - 1" characters and appends a '\0' at the end.
The code is below:
/* read at most size - 1 characters. */
char *get_input_from_stdin_and_discard_extra_characters(char *str, int size)
{
char c = 0;
int num_chars_to_read = size - 1;
int i = 0;
if (!str)
return NULL;
if (num_chars_to_read <= 0)
return NULL;
for (i = 0; i < num_chars_to_read; i++) {
c = getchar();
if ((c == '\n') || (c == EOF)) {
str[i] = 0;
return str;
}
str[i] = c;
} // end of for loop
str[i] = 0;
// discard rest of input
while ((c = getchar()) && (c != '\n') && (c != EOF));
return str;
} // end of get_input_from_stdin_and_discard_extra_characters
Just for completeness, in your case if you actually want to use scanf which there are plenty of reasons not to, I would add a space in front of the format specifier, telling scanf to ignore all whitespace in front of the character:
scanf(" %c", &ch1);
See more details here: https://en.cppreference.com/w/c/io/fscanf#Notes
Short, portable and declared in stdio.h
stdin = freopen(NULL,"r",stdin);
Doesn't get hung in an infinite loop when there is nothing on stdin to flush like the following well know line:
while ((c = getchar()) != '\n' && c != EOF) { }
A little expensive so don't use it in a program that needs to repeatedly clear the buffer.
Stole from a coworker :)