alternative for fflush(stdin)

To my horror, i just realised fflush(stdin) is suppose to have undefined behaviour. Can someone tell a proper alternative to remove unwanted characters in the input stream?

One way:

Code:

---

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

---

Another way:

Code:

---

scanf ( "%*[^\n]" );
scanf ( "%*c" );

---

Another variation:

Code:

---

scanf ( "%*[^\n]" );
getchar();

---

Of course, if you find yourself doing this a lot you should wonder why your input constructs aren't being used more elegantly.

Code:

---

int ch;
while ( (ch=getchar()) != EOF && ch != '\n' ) { /* nothing */ }

or more tersely
while ( (ch=getchar()) != EOF && ch != '\n' );

---

The problem pretty much goes away once you stop using scanf() for reading input and always use fgets(). fgets() is far more predictable about how much data it will read from a stream.

So

Code:

---

int myint;
scanf("%d",&myint);
// some hacky flush

---

Would become

Code:

---

int myint;
char buff[BUFSIZ];
fgets( buff, sizeof buff, stdin );
sscanf( buff, "%d", &myint );

---

Code:

---

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

---

sorry, but i dont understand why do u need to compare the character with '\n' and eof. why not just eof? since basically, u want to flush everything in the stream?

And what this mean?

Code:

---

scanf ( "%*[^\n]" );

---

i understand %[^\n] is used to match anything except the newline, but what is * for?

>since basically, u want to flush everything in the stream?
When a program asks you for input, do you use the enter key or the EOF control combination to end your input? Chances are you've done both, so we test for both so that a loop doesn't get hung waiting for EOF when your input was terminated with a newline.

>but what is * for?
It means throw away whatever is read. You don't need it since it's supposedly garbage, so why assign it to valuable memory?

Prelude.

Is there a chance of catching Ctrl+Z or F6 (EOF) using a signal handler?

signal(?, func);

Quote:

---

Originally posted by c99
Prelude.

Is there a chance of catching Ctrl+Z or F6 (EOF) using a signal handler?

signal(?, func);

---

I don't believe there is, EOF is passed to the application via a read call of some sort (fgets etc).

Out of interest, to see what signals are being sent by what action, you can always try something like this to trap every signal and go from there:

Code:

---

#include <stdio.h>
#include <signal.h>

void handler(int sig)
{
  printf ("Got signal %d\n", sig);
}

int main(void)
{
  int i;
  char buf[BUFSIZ];
 
  for (i = 0; i < NSIG; i++)
  {
    signal(i, handler);
  }
 
  fgets(buf, sizeof(buf), stdin);
 
  return(0);
}

---

Hammer.

Thanks, seems I can only manage to raise one signal from kbd action, SIGINT (Ctrl+C).

Quote:

---

Originally posted by Hammer
Out of interest, to see what signals are being sent by what action, you can always try something like this to trap every signal and go from there:

Code:

---

#include <stdio.h>
#include <signal.h>

void handler(int sig)
{
  printf ("Got signal %d\n", sig);
}

int main(void)
{
  int i;
  char buf[BUFSIZ];
 
  for (i = 0; i < NSIG; i++)
  {
    signal(i, handler);
  }
 
  fgets(buf, sizeof(buf), stdin);
 
  return(0);
}

---

---

I don't believe it is correct to call printf (or most other standard library functions) in a signal handler that is invoked asynchronously.

Ok, now i understand how to flush properly. Thanks guys.

Code:

---

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

---

sorry for the, most likely, dumb question but is there any particular reason to use an int and not a char there?

Quote:

---

Originally Posted by killme

sorry for the, most likely, dumb question but is there any particular reason to use an int and not a char there?

---

Because getchar() returns an int value, and because EOF may be (in fact, usually is in practice) a value that can be represented correctly using an int but not using a char.