To fflush, or Not to fflush...

I am going through the C for Dummies tutorials and have run into a problem using fflush.

Code:

---


#include <stdio.h>

int main()
{
        char c,d;
       
        printf("Enter a key, blah blah blah:\n");
        c=getchar();

        fflush(stdin);

        printf("Enter a different key, blah blah blah:\n");
        d=getchar();

        if(c=='G' || c=='g' && d=='0')
        {
                printf("**** AUTO DESTRUCT ACTIVATED ****\n");
                printf("****        GOODBYE        ****\n");
        }

        else
        {
                printf("Nice job moron.\n");
        }
        return (0);
}

---

A) When I use fflush, it compiles just fine, no errors.
But when the program runs, and I type e I get the following result:

Enter a key, blah blah blah:
At the prompt I can type a letter...I choose 'e', then hit return and it spits out the next three lines, end program.
e
Enter a different key, blah blah blah:
Nice job moron.

B) When I use fpurge the compiler returns an error that reads:

ld: Undefined symbols:
___gxx_personality_v0




Sorry for the lengthy description, can anyone help me out?
Bryan a.k.a. New Guy

If fflush(stdin) is really in the book, then the author is a dummy himself.

Why fflush(stdin) is wrong. One would think that somebody would have told mr Gookin this by now. Perhaps he was not listening.

I had to #include another header besides <stdio.h> in order to use fpurge. Maybe look into that. If you search the board you will likely find plenty of decent ways of clearing the input buffer.

fflush(stdin) is not entirely wrong, it's just not 'standard C'. Many compilers do support it, like MSVC. It all depends on which compiler you are using and whether you want your program to conform to 'standard C' or not.

>fflush(stdin) is not entirely wrong
If you want to use it in your own code, that's up to you. But around here, if the standard says it's undefined, it's wrong.

>Many compilers do support it
And many more do not. For example, since we're naming popular compilers, GCC doesn't support fflush ( stdin ).

Let's just say that extensions should generally be avoided until one knows the standard language, and refrain from rationalizing constructs that are dangerous. You wouldn't want to encourage bad behavior just be cause "it works for you", would you?

Quote:

---

But around here, if the standard says it's undefined, it's wrong.

---

I wasn't aware that was a rule on this board.

If conforming to 'standard C' is a requirement, then yes, it is wrong.

Just pointing out that some compilers do support it, and that is why it is seen in some code examples.

Thank you for your response.
The puzzler here is that fflush doesn't register an error when compiling, yet it doesn't work.
fpurge ALSO recommended by Mr. Gookin (he does mention that fflush isn't the only way to do it) DOES return an error during compiling!?
I have looked through the forum, and there seem to be really complex ways to clear the input buffer...

I would like to know how to figure out what I AM supposed to use with the gcc compiler?

My shell recognizes man fflush and fpurge as the same thing, they effect differently and neither of them works!?

Definitely don't like being the new guy with the stoopid questions!
Apologies,

Rather than relying on flushing stdin, simply read all of the data in every time. Use somethign such as fgets to read an entire line in at a time and then process it. That way you don't leave anything on the buffer that shoudln't be there and you don't ahve to worry abotu fllushing. The reason ffllush'ing input buffers is undefined is because your process does not generally control an input buffer, something else does and you are reading it. So you don't have permissions to flush something you don't own. On top of that, fflush'ing something you read from does not really make sense. flushing does not mean 'throw away' data.

Quote:

---

Originally Posted by n7yap

I wasn't aware that was a rule on this board.

If conforming to 'standard C' is a requirement, then yes, it is wrong.

Just pointing out that some compilers do support it, and that is why it is seen in some code examples.

---

a book that tries to teach you about C should not include code like that.

People who have no experience will automatically assume this is correct and start to use the construct in their own code. At some point they will have to unlearn it. When you switch to a compiler that doesnt support it for instance. Hey my code crashes suddenly and I have no idea what I'm doing wrong.
Or when you start to work in a team where all the others start telling you you're a bad programmer because you dont even know that flushing stdin is undefined.

Quote:

---

Originally Posted by orbitz

Rather than relying on flushing stdin, simply read all of the data in every time. Use somethign such as fgets to read an entire line in at a time and then process it. That way you don't leave anything on the buffer that shoudln't be there and you don't ahve to worry abotu fllushing. The reason ffllush'ing input buffers is undefined is because your process does not generally control an input buffer, something else does and you are reading it. So you don't have permissions to flush something you don't own. On top of that, fflush'ing something you read from does not really make sense. flushing does not mean 'throw away' data.

---

Although even when using fgets() there will be characters left in the buffer if the size of the storage is less than the amount of characters entered by the user.

>I wasn't aware that was a rule on this board.
When you're trying to be a sarcastic prat, it's customary to use the :rolleyes: smiley. ;)

>If conforming to 'standard C' is a requirement, then yes, it is wrong.
Okay, try to understand it from our perspective. Most of the time the OP fails to tell us what compiler he is using, so 'standard C' is the only set of requirements we can go by. Even if he does mention his compiler, that doesn't change the fact that while any decent compiler will suitably conform to the standard, reliance on a feature that is clearly broken (even if it happens to work) is silly to the extreme.

>Just pointing out that some compilers do support it
Whether intentionally or not, you were encouraging it. I don't care if you encourage a non-portable feature; any non-trivial program has to use them, but I greatly disapprove of any non-portable feature that is hopelessly broken, yet fails to produce a diagnostic message in half of the compilers that use it.

Quote:

---

To fflush, or Not to fflush...

---

If it's yellow, let it mellow.
If it's brown, flush it down.

Prelude,

I get the impression you are a moderator here. If the scope of this board is programming in Standard C only, then it should be stated in the rules or guidelines. If that is the case, then I will abide by it, but I have read the rules and the guidelines and the stickeys, and I haven't seen that stated anywhere. It seems every time anyone, including me, mentions something that is not standard C on this board, they get flamed for it, often by you. So unless it is stated that the discussion here is to be standard C only, you need to widen your perspective and BACK OFF. I'm all for C standards, especially C99, but C programming does include using non-standard features of the compiler, calling API functions (whether Windows, Linux, Unix, Mac or whatever), inline assembly etc. If you limit yourself to standard C only, your programs are not going to be very interesting (or marketable).

You call that a flame? You didn't do anything wrong, Prelude was just correcting you to what should have been said.

i agree, the point of this board is to help people, and to help
people the best way, and standard code is the best way.
i think you should welcome the information, and use it.
prelude is hardly wrong when it comes to this board
and programming in general, you should take her word
for everything its worth i know i do, her post have taugh me
much, and since im a a$$hole admitting that was hard, but
worth the effort.

>I get the impression you are a moderator here.
No, just a concerned citizen.

>then it should be stated in the rules or guidelines.
That's just it, we don't force you to stick to the standard, but it is encouraged unless there is a good reason to stray. For example, if someone asks how to clear the screen in Linux, we'll go through the whole row about whether clearing the screen is necessary, the disadvantages, and that there's no portable way to do it. However, despite these warnings, we will still provide a non-portable solution because we have enough information to do so. Putting a global ban on all things non-standard is just plain dumb, as you clearly understand.

>It seems every time anyone, including me, mentions something
>that is not standard C on this board, they get flamed for it, often by you.
Often by me? Should I assume that you've been lurking for several years and keeping count? Seriously, nobody is flamed for talking about non-standard features. They may be corrected in such a way that could be construed as flaming, but the only real flames come when someone (such as yourself) encourages a feature that works for them, but breaks in a gloriously hideous manner just about everywhere else (such as fflush ( stdin )).

>you need to widen your perspective and BACK OFF
I could say the same about you.

>If you limit yourself to standard C only, your programs are not going to be very interesting (or marketable).
If you're learning C, then the worst thing you could do is learn an implementation rather than the language proper. And as for your general statement about standard C being useless, I write programs every day that conform to the standard that are terribly interesting, and I make a good living doing it.

Quote:

---

Originally Posted by Prelude

And as for your general statement about standard C being useless, I write programs every day that conform to the standard that are terribly interesting, and I make a good living doing it.

---

You have no idea how often I curse about this. Every time we start working with interesting data structures, I think "Damn...wish we could have hired Prelude."

Prelude,

I was not encouraging the use of fflush(stdin).

I stand by what I said.

n7yap,

Why do you think you are getting flamed? All she was doing was explaining that why it is not the best idea to encourage someone who is learning to use non standard code.

When I am coding I want to know what my code is going to do not what it could maybe do. So relax and listen with the intention to learn something instead of listening with a huge chip on your shoulder to some really good advice.

Quote:

---

Originally Posted by kermit

Although even when using fgets() there will be characters left in the buffer if the size of the storage is less than the amount of characters entered by the user.

---

Yes, and fgets provides you with methods of figuring out if you have read all of the data or not.

dont mistake me though, i was flaming you.
you leave my woman (prelude) alone. :)

The board rules don't say anything about the standard, but Prelude ( as always ) is right: In the majority of posts we don't know what compiler is used and even if we know, it's better to suggest a standard compliant way so people who are interested and find this thread through googling later on ( looking around here I get the impression that googling is some kind of black magical art that only a few chosen can use, but that's not the point ) ... err... anyway, the reply should help all people, not just the specific poster, so if it can be reached by teaching the standard compliant way to everyone, that would be perfect.

There are more than enough tasks that require non-standard methods later on, so we should keep to it as long as possible :)

nvoigt,

Thanks for the reply. I understand.

It's not the first time Prelude has gotten on my case for posting about something that is not standard C, so it kind of struck a nerve.

It's rather amusing that you with your C99 avatar apparently so frequently post the use of non-standard functions.


Quzah.

Quote:

---

Originally Posted by n7yap

It's not the first time Prelude has gotten on my case for posting about something that is not standard C

---

What? You didn't learn the first time?

quzah,

I fully support C standards, and I think C99 is great. But I also don't limit myself to standard C only.

I can see the point that when you are teaching someone C, sticking to the standards is a very good idea.

I came here not necesarily to learn and not necesarily to teach, but for interesting discussion about C. I think I'm in the wrong place.

Quote:

---

Originally Posted by ILoveVectors

dont mistake me though, i was flaming you.
you leave my woman (prelude) alone. :)

---

Woah theres a woman here :D

Quote:

---

Originally Posted by n7yap

I came here not necesarily to learn and not necesarily to teach, but for interesting discussion about C. I think I'm in the wrong place.

---

No, you just got in a huff for no reason other than the fact that people told you your code wasn't gold-plated. You post code for public consumption, they're going to tell you what they think of it. If you don't like people commenting on your posts, don't post. If you do want to post, don't be so thin-skinned. Personally I don't care if you post or not.


Quzah.

quzah,

I didn't post any code.

>It's not the first time Prelude has gotten on my case for posting about
>something that is not standard C, so it kind of struck a nerve.
Well, seeing as how I've only challenged you two times aside from this thread, one of those times you asked us to shred your code and the other was concerning keeping the input buffer tidy, I don't see how I've ever gotten on your case for something non-standard before now. Perhaps you simply misinterpreted my comments in the past as some sort of insult. If that's the case then I appologize. I wouldn't want you to be insulted unless I'm actually insulting you. ;)

Sorry Prelude, it wasn't you, my mistake. :o

Somebody please lock this dam thread.

Works for me -