fflush( ) questions

I read the FAQ entry on why not to use fflush(stdin), but all it said was that the behavior is undefined...so I'm sort of confused? Like what kind of horrible consequences could arise?

Also I was trying to clear the screen and someone suggested using fflush(stdout), but that only seems to work the first time I call it, and after that nothing happens. Why exactly is that? I mean I know I could use clrscr(), or system("CLS") since dev doesn't have clrscr().

So I guess those are my only two questions. Somewhat trivial, but it was something that was sort of bugging me so I felt the urge to ask ^_^

The most likely thing to happen is that it simply won't work, making it pointless to do. fflush doesn't clear a screen. It writes everything in the buffer to the stream. For example, if you've done:

Code:

---

printf("hello world");

---

There is no newline, and so if the buffer is not full, it doesn't have to display what you've asked it to. If you want to make sure it does, you can flush the stream; forcing it to write everything that hasn't been written yet.


Quzah.

For the first, undefined behavior means just that. Behavior which isn't defined. We don't know what's going to happen. Your computer could explode. Or nothing could happen.
fflush(stdout) doesn't clear the screen. It only makes sure that whatever is in the output buffer gets shown on the screen. There should be an additional entry in the FAQ about how to clear the screen, I do believe.

but what's the point of creating fflush function if it would have undefined behavior?

Quote:

---

Originally Posted by nik2

but what's the point of creating fflush function if it would have undefined behavior?

---

The behavior is only undefined when applied to an INPUT stream.

The fact that fflush(stdin) will generally work does not change the fact that you are flushing an INPUT stream, potentially resulting in undefined behaviour.

Once you intentionally introduce undefined behaviour into your program, you cannot be sure that it is not somehow the cause of any and all subsequent problems you may have -- meaning debugging with confidence is impossible.

Quote:

---

Originally Posted by nik2

but what's the point of creating fflush function if it would have undefined behavior?

---

The function takes a file handle. It doesn't know if the file has been open for reading or writing.

Consider all of the string functions. They all take pointers to characters as their arguments. None of them actually know how much space is really being pointed at. It's up to you to use them correctly.

Code:

---

char x, y;

strcpy( &x, &y );

---

This function sees two pointers to characters, and says "Ok, I can use those...". It doesn't know that x and y are singular characters. It doesn't know if they are valid strings (they could actually BE valid strings--a single nul character is a valid string).

The same goes for fflush. It gets a FILE* and expects you to pass it the right thing. It's not its fault if you pass it something incorrectly. If you really want to, you can crash your program with most standard library functions.


Quzah.

> Like what kind of horrible consequences could arise?
Because C is the kind of language where if you make statements like "I want to hang myself", it will happily give you the rope to do it (see Quzah's string example).

There is no safety net - you need to have some sense of what it is you're actually trying to do. Writing a syntactically valid C program is pretty easy - about 10% of the effort. Making sure it behaves within all the other rules (like not flushing input streams) is where you differentiate yourself from the crowd.

Further, just because you made it run without crashing, and got the results you expected only puts you at about 75% done. Porting the code to other systems (or just changing the optimisation flags) often reveals yet more problems with the code.

Okay I suppose I understand what you're all getting at. I think at this point in my knowledge it's one of those things I just shouldn't do. I don't use the fflush "method" since my compiler has the clrscr() function(and the few times I've asked about it everyone has practically had a conniption), but I was really curious as to why it was practically a taboo...and I think you guys cleared it up ^_^

Salem, I find it funny and ironic that your signature reads this: "If you dance barefoot on the broken glass of undefined behaviour, you've got to expect the occasional cut." It's probably referring to something else, but it's still ironic xD

I believe it refers to that if you invoke undefined behavior, you have to expect trouble. Things that fail to work properly, for example.
Such as flush stdin. It will not work the same across all compilers and platforms. If you port undefined behavior, you have to expect that they'll break.