O_oQuote:
To call fflush(stdin) "garbage" seems an emotional (anti-windows) reaction.
Now who's trying to start something? [Edit]Yes. That was a joke.[/Edit]
Seriously though, you are being paranoid--at least "fanboyish"--if you think my reaction is born of being "anti-windows". (I am more "pro-standard" and "pro-do what it says on the label".) To be clear, I'd call any other mechanism the standard doesn't cover masquerading as standard behavior garbage; for example, I'd call it garbage when a vendor ships a `strdup' with "string.h". (Yes, I also called it garbage when Borland liked to pretend that "graphics.h" was standard.) If the mechanic was provided under `void _fpurge(FILE*)' with "string.h" or `void fpurge(FILE *)' in a header not shipping as standard I would not have a problem with the mechanic being provided. So, I do not have a problem with the mechanic.
Of course, I do also have a problem with the name `fflush' in respect to streams open only for reading. Seriously, what does `fflush(stdin)' say? Clear any errors? Read until the next token? Read until the next line? Restore characters already consumed as part of the previous read operation?
As for the mechanism, a strategy for processing input with `fgets' followed by formatting has already been referenced, and when done properly, you don't need a system specific `fflush(stdin)' because the underlying stream isn't being tasked with "dirty" input. (You only ask for characters, and you only get characters.) I'm not against a form of "reset" being available, but I would not want an application I'm using to throw away my input "until newline" just in case I've entered multiple values on one line.
The argument that Microsoft should have the final say with extensions to C on "Windows" simply because they ship both "Windows" and a compiler is ridiculous. Your opinion necessarily results in and of believing that one vendor should have final say on "undefined behavior". Where does this end? How do you choose which vendor sets the standard? Are you going to pick and choose other extensions regarding "undefined behavior"? Does one vendor get the final word on all "undefined behavior"? Feel free to hold whatever opinion you wish, but you are building on flawed logic; the code is "undefined behavior" so you shouldn't be relying on it regardless of your opinion.Quote:
In my opinion, a sane gcc build for a windows environment should define fflush(stdin) to either do nothing or to do what the windows compiler runtime does.
*shrug*
That is what "undefined behavior" means.
[Edit]
Also, your compiler has nothing to do with the availability of a `fflush(stdin)' defined as clearing errors/consuming input until newline; the availability is found within the standard library "runtime". With your build of "GCC", assuming a "MinGW" variant, you are almost certainly using the same "MSVCRT.DLL" as distributed by Microsoft with earlier "Visual C++" environments which has long been a shipping part of "Windows".
I don't mean to be harping on this idea, but the notion of the "runtime" behaving differently with this bit of "undefined behavior" is exactly the issue being discussed.
[/Edit]
Soma