flush(stdin)

[Darklight]

is this correct or incorrect i just read the post below before posting
this: In fflush(stdin), what happens to flushed data?

this program is taken from sams teach yourself c in 21 days

/* LIST13-6.C CLEARING STDIN OF EXTRA CHARACTERS */
/* USING FFLUSH() FUNCTION */
#include<stdio.h>

int main(void)
{
int age;
char name[20];

/* PROMPT FOR USER'S AGE */
puts("Enter age: ");
scanf("%d",&age);

/* CLEAR STDIN OF ANY EXTRA CHARACTERS */
fflush(stdin);

/* PROMPT FOR USER'S NAME */
puts("Enter your name: ");
scanf("%s",name);

/* DISPLAY DATA */
printf("Your age is %d\n",age);
printf("You name is %s\n",name);

return 0;
}

my os is suse 9.1 pro
the fflush function dosn't work.
would the above program work in windows
if i replace the flush function with

void clear_kb(void)

/* CLEARS STDIN OF ANY WAITING CHARACTERS */
{
char junk[80];
fgets(junk,80,stdin);
}

the above program works

 

[Ben Pfaff]

is this correct or incorrect i just read the post below before posting
this: In fflush(stdin), what happens to flushed data?

fflush(stdin) yields undefined behavior. From the FAQ:

12.26: How can I flush pending input so that a user's typeahead isn't
read at the next prompt? Will fflush(stdin) work?

A: fflush() is defined only for output streams. Since its
definition of "flush" is to complete the writing of buffered
characters (not to discard them), discarding unread input would
not be an analogous meaning for fflush on input streams.

There is no standard way to discard unread characters from a
stdio input stream, nor would such a way necessarily be
sufficient, since unread characters can also accumulate in
other, OS-level input buffers. You may be able to read and
discard characters until \n, or use the curses flushinp()
function, or use some system-specific technique. See also
questions 19.1 and 19.2.

References: ISO Sec. 7.9.5.2; H&S Sec. 15.2.

this program is taken from sams teach yourself c in 21 days

Then you should throw away that book. It is a menace.

 

[Malcolm]

is this correct or incorrect i just read the post below before posting
this: In fflush(stdin), what happens to flushed data?

fflush() isn't defined for input streams. It could do nothing, it could
cause an error to be reported, or it could clear the buffer of waiting
characters.

this program is taken from sams teach yourself c in 21 days

/* LIST13-6.C CLEARING STDIN OF EXTRA CHARACTERS */
/* USING FFLUSH() FUNCTION */
#include<stdio.h>

int main(void)
{
int age;
char name[20];

/* PROMPT FOR USER'S AGE */
puts("Enter age: ");
scanf("%d",&age);

/* CLEAR STDIN OF ANY EXTRA CHARACTERS */
fflush(stdin);

/* PROMPT FOR USER'S NAME */
puts("Enter your name: ");
scanf("%s",name);

/* DISPLAY DATA */
printf("Your age is %d\n",age);
printf("You name is %s\n",name);

return 0;
}

my os is suse 9.1 pro
the fflush function dosn't work.

The book isn't very good, since it is teaching bad habits.

would the above program work in windows
if i replace the flush function with

void clear_kb(void)

/* CLEARS STDIN OF ANY WAITING CHARACTERS */
{
char junk[80];
fgets(junk,80,stdin);
}

the above program works

Unfortunately, all the input functions block if there is no character
waiting. So calling fgets() isn't a particularly good solution.

 

[Martin Ambuhl]

is this correct or incorrect i just read the post below before posting
this: In fflush(stdin), what happens to flushed data?

Who knows? fflush is not defined for input streams.

this program is taken from sams teach yourself c in 21 days

So burn the book.

 

[Gordon Burditt]

is this correct or incorrect i just read the post below before posting

this: In fflush(stdin), what happens to flushed data?

The programmer loses his/her job. In pathological cases where stdin
is connected to the keyboard, the user may be forced to untype the
data s/he last input. This can be particularly dangerous if the
user is no where near the keyboard and is driving a car at high
speed.

It is illegal per just about every plumbing code to flush water
back into a water tap. This contaminates the water supply.
fflush(stdin) tries to do the analagous thing with data.

Gordon L. Burditt

 

[Keith Thompson]

The programmer loses his/her job. In pathological cases where stdin
is connected to the keyboard, the user may be forced to untype the
data s/he last input. This can be particularly dangerous if the
user is no where near the keyboard and is driving a car at high
speed.

It is illegal per just about every plumbing code to flush water
back into a water tap. This contaminates the water supply.
fflush(stdin) tries to do the analagous thing with data.

The conclusion is correct, but the reasoning is overstated. There is
a perfectly reasonable interpretation for "flushing" an input stream,
particularly an interactive one. In the case of reading from a
keyboard, it could discard any input that's been entered but not yet
processed by the program, discarding any typeahead buffer. This could
be a very useful thing to be able to do in some circumstances. (I'm
not sure how meaningful it could be for non-interactive input; I'd
have to think about it, but I'm unwilling to do so. })

The only problem is that the language doesn't support such an
operation. fflush(stdin) invokes undefined behavior because the
standard says so. If the standard defined the behavior of
fflush(stdin) (as it could have done), it would behave as defined.

This is not to imply that I think the standard *should* define the
behavior of fflush(stdin). The obvious semantics are too specific to
interactive keyboard input; defining the semantics in other cases is
perhaps more effort than it's worth.

 

[Gordon Burditt]

is this correct or incorrect i just read the post below before posting

The conclusion is correct, but the reasoning is overstated. There is
a perfectly reasonable interpretation for "flushing" an input stream,
particularly an interactive one.

It may be a reasonable interpretation, but it is NOT a reasonable
thing to do (neither is pissing up a water tap).

In the case of reading from a
keyboard, it could discard any input that's been entered but not yet
processed by the program, discarding any typeahead buffer. This could

On a machine that might be loaded or connected by a slow or bursty
network link, this is a problem. The user never knows when the
flush happens (even after the prompt is output, it might not happen
until the user has typed 9 or 79 characters, or it might happen
immediately), and the possibility of having the first part of your
input lopped off at any point makes it unsafe to use the program
if it does anything significant (like writing on existing files, or
quitting after you've spent some time putting in data).

Eject warp core [n]?

I type Y followed by newline, but the flush happens between the Y
and the newline, which is taken as a NO. If you really need to
eject a warp core, you may not get a second chance to do it (and
no, the default should NOT be changed to YES).

be a very useful thing to be able to do in some circumstances. (I'm

What circumstances? There are a number of programs where this is
used, including some newsreaders, and I've found it a problem in
all of them. The better ones let you turn it off.

If the user went to the trouble of typing it, the program should
go to the trouble of paying attention to it - even if it's just
reading and discarding to the next newline.

not sure how meaningful it could be for non-interactive input; I'd
have to think about it, but I'm unwilling to do so. })

The only problem is that the language doesn't support such an
operation. fflush(stdin) invokes undefined behavior because the
standard says so. If the standard defined the behavior of
fflush(stdin) (as it could have done), it would behave as defined.

This is, of course, true of anything specified as undefined behavior:
division by zero, dereferencing a NULL pointer, fflush(main),
strcpy(NULL, "Hello, world"), etc.

Gordon L. Burditt

 

[Keith Thompson]

It may be a reasonable interpretation, but it is NOT a reasonable
thing to do (neither is pissing up a water tap).

[snip]

Perhaps. The main point of my response, however, is that
fflush(stdin) invokes undefined behavior because the standard says so.
If you argue which operations are valid on the basis of which ones
make sense, no two people are going to get the same answer; one person
might think that strlen(NULL) obviously should quietly return 0 (or
-1), another might think that unsigned overflow should cause a trap.
The choices aren't always obvious, and the particular choices made by
the standard are sometimes arbitrary.

 

[Mark McIntyre]

There is
a perfectly reasonable interpretation for "flushing" an input stream,

IMHO the action of emptying the input buffer is not analagous to typical
flushing operations (aside from possibly colonic irrigation....) since
flushing typically means pushing out rather than sucking out....

The only problem is that the language doesn't support such an
operation. fflush(stdin) invokes undefined behavior because the
standard says so.

More accurately, it says it because no reasonable meaning can be given to
it in some quite trivial and commonplace cases. This is unlike
fflush(stdout), where /you/ can be sure how much data needs to be pushed,
since you put it in the buffer in the first place.

If the standard defined the behavior of
fflush(stdin) (as it could have done), it would behave as defined.

Yes, but how to define it, given that stdin could be a pipe from say
chargen, or a blocking network device?

This is not to imply that I think the standard *should* define the
behavior of fflush(stdin).

*whew*

 

[CBFalconer]

.... snip ...


More accurately, it says it because no reasonable meaning can be
given to it in some quite trivial and commonplace cases. This is
unlike fflush(stdout), where /you/ can be sure how much data needs
to be pushed, since you put it in the buffer in the first place.


Yes, but how to define it, given that stdin could be a pipe from say
chargen, or a blocking network device?


*whew*

However, unlike the proposals of M.Navia, this could be added to C,
for text files only. We say that all input routines operating on
textfiles act as if they are calling getc the appropriate number of
times. Now we add a flag, not visible to the user, interior to the
FILE structure, which we will call the eoln flag. This is reset,
until a \n is delivered to the user, when it is set. It can be
reset by any other reading action, including pushing back a \n with
unget. The purpose of this flag is to make fflush(inputtextfile)
have consistent behavior.

fflush(inputtextfile) now discards characters until the eoln flag
is set or EOF is reached. It does nothing if the eoln flag is
initially set.

Since the eoln flag is not user visible, there is no compatibility
problem. It's only purpose is to make fflush usable. If input is
from some other device, such as the 'blocking network device'
mentioned above, it can simply leave the FILE in a discarding mode
and return immediately. The actual blocking will then occur on a
future read operation, as far as the application is concerned.

 

[tigervamp]

is this correct or incorrect i just read the post below before posting
this: In fflush(stdin), what happens to flushed data?

this program is taken from sams teach yourself c in 21 days

/* LIST13-6.C CLEARING STDIN OF EXTRA CHARACTERS */
/* USING FFLUSH() FUNCTION */
#include<stdio.h>

int main(void)
{
int age;
char name[20];

/* PROMPT FOR USER'S AGE */
puts("Enter age: ");
scanf("%d",&age);

/* CLEAR STDIN OF ANY EXTRA CHARACTERS */
fflush(stdin);

/* PROMPT FOR USER'S NAME */
puts("Enter your name: ");
scanf("%s",name);

/* DISPLAY DATA */
printf("Your age is %d\n",age);
printf("You name is %s\n",name);

return 0;
}

As others have pointed out, fflush behavior is only defined when
working on output streams. Funny thing is, I had this same book on my
bookshelf (don't remember where it came from, never really used it
before), picked it up to look something up just the other day, and
opened it up to the page with the above example. For some reason it
caught my eye and when I realized what what going on I decided maybe I
should not look for my answer in this book. It is no longer on my
bookshelf. Cursory examination reveals other sloppiness. I recommend
you find another book.

my os is suse 9.1 pro
the fflush function dosn't work.

<OT>
According to the man page on my suse 9.1 pro, the glibc provided fflush
function conforms to the ANSI C standard and doesn't mention any
specialized behavior. It also indicates that it operates on output
streams in the description.
</OT>

Rob Gamble

 

[Mark McIntyre]

However, unlike the proposals of M.Navia, this could be added to C,
for text files only.

I think you're right, though the Standard might then have to define "text
file" a little more rigorously than the current nonexistent definition!

And you (or Jacob) might then ask, why stop with text files - why not also
define it for other input stream types? You could easily define a meaning
for buffered input devices for example.