Flush Input Buffer

Since fflush() is illegal, and rewind() is not guaranteed to work, is this legal, and more importantly, function the way I'm intending it to?

Code:

---

#include <stdio.h>
#include <stdlib.h>
#include <stdbool.h>

// Flush input buffer (actually, any buffer)
//
// Parameters:
//    FILE* stream    Pointer to file to be 'debuffered'.
// Returns:
//    bool - false if error, true if successful.
// Notes:
//    For output streams, does not mimic fflush() in that remaining
//    data is lost.
inline bool Flush_Stream(FILE* stream)
{
    void* p = malloc(BUFSIZ);
    if (p == NULL)
        return false;

    setbuf(stream, p);
    return true;
}

---

I don't believe so. At least, not if I'm understanding the man page correctly. Actually, there is no standard way you can have unbuffered input, so you don't even need to try.

Wait a second. Flushing the input stream and unbuffering it are two different things. Unbuffering refers to making it non-buffered. Meaning, as soon as you press a key, it is sent immediately. (IE: Not buffered.)

Flushing the stream simply means to clear out any pending input. That's a snap to do:

Code:

---

void fflushstdin( void )
{
    int c;
    while( (c = fgetc( stdin )) != EOF && c != '\n' );
}

---

Quzah.

Quote:

---

Originally Posted by quzah

Wait a second. Flushing the input stream and unbuffering it are two different things. Unbuffering refers to making it non-buffered. Meaning, as soon as you press a key, it is sent immediately. (IE: Not buffered.)

---

Maybe I didn't use the best terminology, but I did have "debuffered" in quotation marks, so a winnar is me. :-)

Quote:

---

Originally Posted by quzah

Flushing the stream simply means to clear out any pending input. That's a snap to do:

Code:

---

void fflushstdin( void )
{
    int c;
    while( (c = fgetc( stdin )) != EOF && c != '\n' );
}

---

---

That is true, but the relevant FAQ entry states that that will not work if there is no input pending. What I'm trying to accomplish is create a panacea that works whenever wherever.

Well, if there were one that worked in all occasions, it'd already be in the relevant FAQ entry. ;)


Quzah.

Can you use feof() on stdin to see if there's any input pending?

I suppose it would work if there was EOF left in the buffer but I wouldn't rely on it.

> Can you use feof() on stdin to see if there's any input pending?
No, that tells you there will never be any more input.

> void* p = malloc(BUFSIZ);
Way to go with the huge memory leak!

Quote:

---

Originally Posted by Salem

> void* p = malloc(BUFSIZ);
Way to go with the huge memory leak!

---

What memory leak?

Quote:

---

Originally Posted by setbuf() man page

When the first I/O operation occurs on a file, malloc(3) is called, and a buffer is obtained.

---

Well how many free() calls are there for every Flush_Stream() call - bzzzzzt - NONE!!!!

Code:

---

inline bool Flush_Stream(FILE* stream) {
    void* p = malloc(BUFSIZ);
    if (p == NULL)
        return false;

    setbuf(stream, p);

    free(p);
    return true;
}

---

Great - now setbuf() is using free'd memory - nice bun-fight when someone else gets that same block in a following malloc call.

Huh? But the free() call is after the setbuf() call.

I take it you haven't read the manual page on setbuf() to know that it holds onto the pointer you give it, and then uses it as the buffer for future I/O operations.

No, I haven't, sorry. So where would you put the free()?

You can't polish a turd.


Quzah.

Code:

---


inline bool Flush_Stream(FILE* stream)
 {
    void* p = malloc(BUFSIZ);
    if (p == NULL)
        {
            return false;
        }
    else
        setbuf(stream, p);
     
    free(p);
    return true;
}

---

there we go that looks less insane :P
sorry im anal about {} in if statements also you needed an else to be more clear what you wanted to happen in the if statement.

Which still doesn't fix the issue Salem last commented on. In any case, this function still won't do what the origional poster wanted it to, no matter what you do to it.


Quzah.

I just read the man page for setbuf and yea your right that does not make alot of sense.


lol well at least you got me to look at the man page :D now i know what setbuf does YAY !

Code:

---

void flush_stdin(void)
{
char ch = 0;

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

---

This code would always work if you could insert a char into stdin before the loop. Is this possible with any standard c function?

What an entertaining thread. :) I wonder when people will realize that if you do things right to begin with, there's no need to "flush" the input stream.

>This code would always work if you could insert a char into stdin before the loop.
Really? What if char is unsigned?

Ha...I'm kind of glad this thread got resurrected. It was fun to read the first time, and it's still a pretty good read now.

Code:

---

void flush_stdin(void)
{
char ch = 0;

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

---

I could have sworn that getchar() returns an int value and EOF is an int value.

Code:

---

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

---

I took this loop from the faq on this forum, so I guess it´s correct... So do you know a function that inserts chars into stdin?

>I took this loop from the faq on this forum, so I guess it´s correct...
That part is correct, but your little function isn't. Maybe you should read the FAQ more closely. Or better yet, declare ch as unsigned char and see what happens when you assume that getchar returns char.

>So do you know a function that inserts chars into stdin?
Not the way you're thinking of it.

how would you flush stdin?

Yes I agree this is an entertaining thread ;) What everyone failed to mention was that setbuf() must be called immediately after the stream is opened and before any i/o takes place. That pretty much makes the function unusable for stdin unless called at the start of the program in main(). passing NULL to setbuf() makes the stream unbuffered.

There are platform specific methods to rid the input stream of any pending data. Certain unix-like systems provide fpurge (and __fpurge on linux) to do this. As you've discovered, there's no completely portable.

Also, as was said above, there's never any point to doing this anyway. If a user has put stuff on the input stream, that user will expect it to be dealt with, right? In a text based interactive program, you are prompting a user for input. The valid way to deal with "unwanted" cruft on the stream is to parse it and produce an error if appropriate.

If you start trying to "flush" the input stream, you get into deep doodoo when the ambitious user tries to automate your program by piping pre-cooked data into your application. In short, your program becomes far less useful.

But if I use scanf it can always happen that there will be chars left in stdin. Can could I prevent this with scanf or do I have to use another function?

>How could I prevent this with scanf?
Don't mix scanf with other input methods. Use scanf intelligently and you'll have no problems. But an accepted solution is not to use scanf at all in favor of a combination of fgets to read a line and sscanf to parse it.

Ok, thanks now I understood it.

Quote:

---

Originally Posted by zx-1

Since fflush() is illegal, and rewind() is not guaranteed to work, ...

---

what means "fflush() is illegal"? you shouldn't use it anymore?
I normally use fflush(stdin) after fgets()...

Quote:

---

Originally Posted by mabuhay

what means "fflush() is illegal"? you shouldn't use it anymore?
I normally use fflush(stdin) after fgets()...

---

fflush() is ok, when it is used in the proper manner. Read the FAQ on it.

Quote:

---

Originally Posted by kermit

fflush() is ok

---

My compiler, VC++ 6.0, doesn't like it. fflush() requires one parameter. :eek:

>My compiler, VC++ 6.0, doesn't like it. fflush() requires one parameter.
This is precisely why I don't add parens to function names when I'm talking about them. ;) To clarify for everyone who doesn't like anything titled "FAQ", fflush ( stdout ) is good, fflush ( stdin ) is bad. fflush is defined as only working on output streams, and passing it an input stream is undefined according to the standard.

I'm just too lazy to write the parameters... ;)

but, does someone had ever problems using fflush(stdin)?
i think it is known, if you use fgets(some_parameters*g*), that you have to empty the stdin if you want to use fgets again. So why is there no c-function to handle this?

>does someone had ever problems using fflush(stdin)?
Go to a non-Windows system and try to use it.

>if you use fgets(some_parameters*g*), that you have to empty the stdin if you want to use fgets again
Only if the line is longer than your buffer, otherwise fgets has no problems. You're probably thinking of using scanf, then the a newline probably has to be extracted before fgets will do what you want.

>So why is there no c-function to handle this?
Because if you did things the right way to begin with, you wouldn't have problems. ;)

Quote:

---

Originally Posted by mabuhay

I'm just too lazy to write the parameters... ;)
but, does someone had ever problems using fflush(stdin)?

---

Even if fflush(stdin) were somehow "valid", it doesn't even make logical sense. When you flush an output buffer, all data that is buffered will be written out. The logical opposite of this when applied to input buffers is that all data that is buffered will be read in. Guess what does this? Functions that read from the stream (fgets/scanf/fread/getc/etc.).

You don't want to discard input, you want to process it and deal with it.

Quote:

---

Originally Posted by Ancient Dragon

My compiler, VC++ 6.0, doesn't like it. fflush() requires one parameter. :eek:

---

ah - haha

I tend to write my functions that way (with the parentheses) just to indicate I am referring to a function. I never considered that it would be confusing that way though.

Quote:

---

Originally Posted by cwr

...You don't want to discard input, you want to process it and deal with it.

---

Yes, but if I use fgets() I stored my input in a variable but something is still in the input. Or why does it jups over if I use fgets() in the same code again?

Quote:

---

Originally Posted by Prelude

...You're probably thinking of using scanf,...

---

I don't want to use scanf(), because you can't define the input-length globally.

Ok, can someone give me a code example how to use fgets() correctly? If i want to take three lines of text one after other, each with maximal 50 characters.

Quote:

---

Originally Posted by mabuhay

Yes, but if I use fgets() I stored my input in a variable but something is still in the input. Or why does it jups over if I use fgets() in the same code again?

---

Really?

Quote:

---

I don't want to use scanf(), because you can't define the input-length globally.

---

You can, it's just not particularly convenient.

Quote:

---

Ok, can someone give me a code example how to use fgets() correctly? If i want to take three lines of text one after other, each with maximal 50 characters.

---

Well, I can illustrate an issue with fgets:

Code:

---

#include <stdio.h>

#define NLINES 3

int main(void)
{
    char buf[NLINES][50];
    int i;
    for (i = 0; i < NLINES; i++)
    {
        printf("Enter line %d: ", i);
        fflush(stdout);
        fgets(buf[i], sizeof buf[i], stdin);
    }
    for (i = 0; i < NLINES; i++)
        printf("Line %d was \"%s\"\n", i, buf[i]);
    return 0;
}

---

Output:

Code:

---

Enter line 0: Line number zero
Enter line 1: A really long line one that exceeds fifty characters
Enter line 2: Line 0 was "Line number zero
"
Line 1 was "A really long line one that exceeds fifty characte"
Line 2 was "rs
"

---

The problem being that fgets will stop reading if it hits the size limit. One way to check to see if fgets has read a whole line is to check for the presence of a \n on the end, and discard further input with another fgets (which may overflow again), or a getchar loop, until you reach the actual end of line.

Quote:

---

Originally Posted by cwr

One way to check to see if fgets has read a whole line is to check for the presence of a \n on the end

---

That may not always work either if the input stream does not contain a '\n'. For example the last line of a file may not terminate with '\n', in that case fgets() will not put one at the end of the line either.

True, so you should also check for a NULL return or an feof on the stream.

OK, now i got it! If ther are too much characters in the input buffer, the maximal number of characters will be read and the rest will stay in the stdin and if the next scanf() is called, it will take the remaining characters. Because the end of the remaining characters is a "\n" it will straight continue.

now i understand why cwr said:

Quote:

---

...You don't want to discard input, you want to process it and deal with it.

---

i thought, the input that is already processed (copyed in your variable) is still in the stdin.

and Prelude said:

Quote:

---

...You're probably thinking of using scanf...

---

when you use scanf to read just one character (scanf("%c", &character); ) then the next scanf() will be jumped over and it seems that in the variable of the second scanf() is nothing, but there's the "\n" in it.

thx for your help and patience ;)