471,573 Members | 1,409 Online
Bytes | Software Development & Data Engineering Community
Post +

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 471,573 software developers and data experts.

Flush stdin?

I'm aware that there is no ANSI (or POSIX, or any standard, to my knowledge)
way of flushing stdin or any other application-level input buffer, but if
anyone knows a hack or a non-portable way to do this, no matter how obscure
or arcane, I'd appreciate it.
Nov 13 '05 #1
30 45564
Jonathan Neill wrote:
I'm aware that there is no ANSI (or POSIX, or any standard, to my knowledge)
way of flushing stdin or any other application-level input buffer, but if
anyone knows a hack or a non-portable way to do this, no matter how obscure
or arcane, I'd appreciate it.


Um...what does it mean, to flush an input buffer?

If you mean you want to read and discard whatever's in the buffer at
a certain time, under POSIX I suppose you could use non-blocking
reads until they come up empty. I don't think standard C has
non-blocking I/O, does it?

If you mean you want to wipe the buffer's memory space, because the
user entered a password or something, I'd avoid using stdin for such
purposes.

--
Tom Zych
This email address will expire at some point to thwart spammers.
Permanent address: echo 'g******@cbobk.pbz' | rot13
Nov 13 '05 #2

I agree. In any case, he can try setbuf() to use non-buffered streams.

--
Ricardo

Nov 13 '05 #3
"Jonathan Neill" <TY*******@tyler.net> wrote in
news:vl************@corp.supernews.com on Thu 04 Sep 2003 07:16:14p:
I'm aware that there is no ANSI (or POSIX, or any standard, to my
knowledge) way of flushing stdin or any other application-level input
buffer, but if anyone knows a hack or a non-portable way to do this, no
matter how obscure or arcane, I'd appreciate it.


You'd do better asking on a system-specific newsgroup. The geeks there
will know a dozen ways to do this on your specific system (or will know if
it can't be done at all). Here, we deal with Standard C, not any system-
specific extensions to the language. If you have a question about ANSI/ISO
C (up to and including C99, and even including pre-Standard K&R C if you
still need it), this is the best place to ask it. If you want to do
something that is system-specific, ask on a system-specific newsgroup for
the best answers.

http://www.eskimo.com/~scs/C-faq/s19.html -- A list of answers to
questions that can't be answered in Standard C. Read the (rest of the) FAQ
for more info.

Nov 13 '05 #4
Jonathan Neill wrote:
I'm aware that there is no ANSI (or POSIX, or any standard, to my
knowledge) way of flushing stdin or any other application-level input
buffer, but if anyone knows a hack or a non-portable way to do this, no
matter how obscure or arcane, I'd appreciate it.


What do you mean by "flush"? If you mean that you want to discard the
current character and all subsequent characters until exactly one \n has
been discarded (and this is typically what most people want from a
so-called "flush" of stdin), call this function:

#include <stdio.h>

/* constraint: fp must be open for input */
int fpDrain(FILE *fp)
{
int ch = 0;
while((ch = getc(fp)) != EOF && ch != '\n')
{
continue;
}
return EOF == ch;
}

--
Richard Heathfield : bi****@eton.powernet.co.uk
"Usenet is a strange place." - Dennis M Ritchie, 29 July 1999.
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
K&R answers, C books, etc: http://users.powernet.co.uk/eton
Nov 13 '05 #5
Hi,

The problem with non portable solutions is that they tend to be highly
system specific. The solution to the problem must be tailored to the
specifics of the systems where it is intended to be used. Since you
did not describe your system / environment we can not give you a
specific working solution.

For instance there are systems where "fflush(stdin);" actually works
and does what you want (e.g. Microsoft Visual C). Another solution
would indeed be to check your system for a non blocking function to
read from a stream or terminal. To add to the already existant obscure
examples: Microsoft C offers a function called "_kbhit()" to check if
there is pending keyboard input available.

--
Stephan Wilms

"Jonathan Neill" <TY*******@tyler.net> wrote in message news:<vl************@corp.supernews.com>...
I'm aware that there is no ANSI (or POSIX, or any standard, to my knowledge)
way of flushing stdin or any other application-level input buffer, but if
anyone knows a hack or a non-portable way to do this, no matter how obscure
or arcane, I'd appreciate it.

Nov 13 '05 #6
Jonathan Neill wrote:
I'm aware that there is no ANSI (or POSIX, or any standard, to my knowledge)
way of flushing stdin or any other application-level input buffer, but if
anyone knows a hack or a non-portable way to do this, no matter how obscure
or arcane, I'd appreciate it.


It doesn't even mean anything. Read the description of the action of
fflush() on output streams and try to come up with a reasonable analogy for
input streams.

--
Martin Ambuhl

Nov 13 '05 #7

"Jonathan Neill" <TY*******@tyler.net> wrote in message news:vl************@corp.supernews.com...
I'm aware that there is no ANSI (or POSIX, or any standard, to my knowledge)
way of flushing stdin or any other application-level input buffer, but if
anyone knows a hack or a non-portable way to do this, no matter how obscure
or arcane, I'd appreciate it.

Look at :
http://groups.google.com/groups?selm...news.dfncis.de
http://alexvn.freeservers.com/s1/download.html (Flushing non-read input data with using tcflush)
=====================================
Alex Vinokur
mailto:al****@connect.to
http://mathforum.org/library/view/10978.html
=====================================
Nov 13 '05 #8
Jonathan Neill wrote:
I'm aware that there is no ANSI (or POSIX, or any standard, to my
knowledge) way of flushing stdin or any other application-level input
buffer, but if anyone knows a hack or a non-portable way to do this, no
matter how obscure or arcane, I'd appreciate it.


What do you mean by "flush"? If you mean that you want to discard the
current character and all subsequent characters until exactly one \n has
been discarded (and this is typically what most people want from a
so-called "flush" of stdin), call this function:

#include <stdio.h>

/* constraint: fp must be open for input */
int fpDrain(FILE *fp)
{
int ch = 0;
while((ch = getc(fp)) != EOF && ch != '\n')
{
continue;
}
return EOF == ch;
}

--
Richard Heathfield : bi****@eton.powernet.co.uk
"Usenet is a strange place." - Dennis M Ritchie, 29 July 1999.
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
K&R answers, C books, etc: http://users.powernet.co.uk/eton
Nov 13 '05 #9
Hi,

The problem with non portable solutions is that they tend to be highly
system specific. The solution to the problem must be tailored to the
specifics of the systems where it is intended to be used. Since you
did not describe your system / environment we can not give you a
specific working solution.

For instance there are systems where "fflush(stdin);" actually works
and does what you want (e.g. Microsoft Visual C). Another solution
would indeed be to check your system for a non blocking function to
read from a stream or terminal. To add to the already existant obscure
examples: Microsoft C offers a function called "_kbhit()" to check if
there is pending keyboard input available.

--
Stephan Wilms

"Jonathan Neill" <TY*******@tyler.net> wrote in message news:<vl************@corp.supernews.com>...
I'm aware that there is no ANSI (or POSIX, or any standard, to my knowledge)
way of flushing stdin or any other application-level input buffer, but if
anyone knows a hack or a non-portable way to do this, no matter how obscure
or arcane, I'd appreciate it.

Nov 13 '05 #10
Jonathan Neill wrote:
I'm aware that there is no ANSI (or POSIX, or any standard, to my knowledge)
way of flushing stdin or any other application-level input buffer, but if
anyone knows a hack or a non-portable way to do this, no matter how obscure
or arcane, I'd appreciate it.


It doesn't even mean anything. Read the description of the action of
fflush() on output streams and try to come up with a reasonable analogy for
input streams.

--
Martin Ambuhl

Nov 13 '05 #11
Stephan Wilms wrote:
The problem with non portable solutions is that they tend to be highly
system specific.


<captious>

Really? Gosh. I guess that's why they're non-portable, then?

</captious>

--
Tom Zych
This email address will expire at some point to thwart spammers.
Permanent address: echo 'g******@cbobk.pbz' | rot13
Nov 13 '05 #12

"Jonathan Neill" <TY*******@tyler.net> wrote in message news:vl************@corp.supernews.com...
I'm aware that there is no ANSI (or POSIX, or any standard, to my knowledge)
way of flushing stdin or any other application-level input buffer, but if
anyone knows a hack or a non-portable way to do this, no matter how obscure
or arcane, I'd appreciate it.

Look at :
http://groups.google.com/groups?selm...news.dfncis.de
http://alexvn.freeservers.com/s1/download.html (Flushing non-read input data with using tcflush)
=====================================
Alex Vinokur
mailto:al****@connect.to
http://mathforum.org/library/view/10978.html
=====================================
Nov 13 '05 #13
Stephan Wilms wrote:
The problem with non portable solutions is that they tend to be highly
system specific.


<captious>

Really? Gosh. I guess that's why they're non-portable, then?

</captious>

--
Tom Zych
This email address will expire at some point to thwart spammers.
Permanent address: echo 'g******@cbobk.pbz' | rot13
Nov 13 '05 #14
On Fri, 5 Sep 2003 01:16:14 UTC, "Jonathan Neill"
<TY*******@tyler.net> wrote:
I'm aware that there is no ANSI (or POSIX, or any standard, to my knowledge)
way of flushing stdin or any other application-level input buffer, but if
anyone knows a hack or a non-portable way to do this, no matter how obscure
or arcane, I'd appreciate it.


100% ANSI compatible:

/* flush stdin */
/* params: */
/* int c int to hold temorary readed char from stdin */
/* */
/* read from stdin until end of file or end of line reached */
#define FLUSHIN(c) while ((c = getc() != EOF && c != '\n')

stdin is commonly line buffered or unbuffered. In both cases reading
until '\n' is dedected is flushing the input stream. Even when stdin
is set to be block buffered (e.g. as pipe or file it makes sense to
"flush". Because stdin is a text stram, so reading until '\n'
syncronises the stream so that the next coming char will be the first
of a line.

--
Tschau/Bye
Herbert

eComStation 1.1 Deutsch Beta ist verügbar
Nov 13 '05 #15
[snips]

On Fri, 05 Sep 2003 02:23:09 +0000, Tom Zych wrote:
Jonathan Neill wrote:
I'm aware that there is no ANSI (or POSIX, or any standard, to my knowledge)
way of flushing stdin or any other application-level input buffer, but if
anyone knows a hack or a non-portable way to do this, no matter how obscure
or arcane, I'd appreciate it.


Um...what does it mean, to flush an input buffer?


You're sitting at the keyboard, firing in commands to do this, that, the
other thing. In the process, you inadvertently enter some option which
is potentially dangerous... but you're still merrily typing away, while
the potentially dangerous program is figuring out what to do - you're
queuing up your inputs.

The program, realizing that what you asked for is dangerous, puts up a
prompt "Do you really mean this? y/N" and waits for input. However, since
you've already queued up inputs, it may well see an N (or worse, a Y)
and the results range from annoying to disastrous.

'Course, if the program had flushed input, your queued commands would be
lost... but you wouldn't be feeding an unwanted input into the program at
a critical juncture.

In a GUI system, generally, this would be done with a messagebox and your
typing wouldn't make an iota of difference; in a CLI environment, however,
it can matter.

One frequent solution is to flush input; whether that means reading and
discarding inputs until a strictly valid one is obtained (i.e. fgets and
only accepting a 'Y' or an 'N' by itself, ignoring other typed inputs) or
using some other means, the result is the same: attempting to flush the
input buffer.
Nov 13 '05 #16
"The Real OS/2 Guy" <os****@pc-rosenau.de> wrote:

/* flush stdin */
/* params: */
/* int c int to hold temorary readed char from stdin */
/* */
/* read from stdin until end of file or end of line reached */
#define FLUSHIN(c) while ((c = getc() != EOF && c != '\n')

^
There's a ')' missing here. :)

--
What does this red button do?
Nov 13 '05 #17
Kelsey Bjarnason <ke*****@xxnospamyy.lightspeed.bc.ca> wrote:
[snips]

On Fri, 05 Sep 2003 02:23:09 +0000, Tom Zych wrote:

Um...what does it mean, to flush an input buffer?


You're sitting at the keyboard, ...

<SNIP>

I am pretty sure he already knows what (usually) is meant when
people talk about "flushing an input buffer": it is the wrong
term for "draining an input buffer".

Irrwahn.
--
What does this red button do?
Nov 13 '05 #18
On Fri, 5 Sep 2003 01:16:14 UTC, "Jonathan Neill"
<TY*******@tyler.net> wrote:
I'm aware that there is no ANSI (or POSIX, or any standard, to my knowledge)
way of flushing stdin or any other application-level input buffer, but if
anyone knows a hack or a non-portable way to do this, no matter how obscure
or arcane, I'd appreciate it.


100% ANSI compatible:

/* flush stdin */
/* params: */
/* int c int to hold temorary readed char from stdin */
/* */
/* read from stdin until end of file or end of line reached */
#define FLUSHIN(c) while ((c = getc() != EOF && c != '\n')

stdin is commonly line buffered or unbuffered. In both cases reading
until '\n' is dedected is flushing the input stream. Even when stdin
is set to be block buffered (e.g. as pipe or file it makes sense to
"flush". Because stdin is a text stram, so reading until '\n'
syncronises the stream so that the next coming char will be the first
of a line.

--
Tschau/Bye
Herbert

eComStation 1.1 Deutsch Beta ist verügbar
Nov 13 '05 #19
[snips]

On Fri, 05 Sep 2003 02:23:09 +0000, Tom Zych wrote:
Jonathan Neill wrote:
I'm aware that there is no ANSI (or POSIX, or any standard, to my knowledge)
way of flushing stdin or any other application-level input buffer, but if
anyone knows a hack or a non-portable way to do this, no matter how obscure
or arcane, I'd appreciate it.


Um...what does it mean, to flush an input buffer?


You're sitting at the keyboard, firing in commands to do this, that, the
other thing. In the process, you inadvertently enter some option which
is potentially dangerous... but you're still merrily typing away, while
the potentially dangerous program is figuring out what to do - you're
queuing up your inputs.

The program, realizing that what you asked for is dangerous, puts up a
prompt "Do you really mean this? y/N" and waits for input. However, since
you've already queued up inputs, it may well see an N (or worse, a Y)
and the results range from annoying to disastrous.

'Course, if the program had flushed input, your queued commands would be
lost... but you wouldn't be feeding an unwanted input into the program at
a critical juncture.

In a GUI system, generally, this would be done with a messagebox and your
typing wouldn't make an iota of difference; in a CLI environment, however,
it can matter.

One frequent solution is to flush input; whether that means reading and
discarding inputs until a strictly valid one is obtained (i.e. fgets and
only accepting a 'Y' or an 'N' by itself, ignoring other typed inputs) or
using some other means, the result is the same: attempting to flush the
input buffer.
Nov 13 '05 #20
"The Real OS/2 Guy" <os****@pc-rosenau.de> wrote:

/* flush stdin */
/* params: */
/* int c int to hold temorary readed char from stdin */
/* */
/* read from stdin until end of file or end of line reached */
#define FLUSHIN(c) while ((c = getc() != EOF && c != '\n')

^
There's a ')' missing here. :)

--
What does this red button do?
Nov 13 '05 #21
Kelsey Bjarnason <ke*****@xxnospamyy.lightspeed.bc.ca> wrote:
[snips]

On Fri, 05 Sep 2003 02:23:09 +0000, Tom Zych wrote:

Um...what does it mean, to flush an input buffer?


You're sitting at the keyboard, ...

<SNIP>

I am pretty sure he already knows what (usually) is meant when
people talk about "flushing an input buffer": it is the wrong
term for "draining an input buffer".

Irrwahn.
--
What does this red button do?
Nov 13 '05 #22
Kelsey Bjarnason wrote:
The program, realizing that what you asked for is dangerous, puts up a
prompt "Do you really mean this? y/N" and waits for input. However, since
you've already queued up inputs, it may well see an N (or worse, a Y)
and the results range from annoying to disastrous.
<snip>
One frequent solution is to flush input; whether that means reading and
discarding inputs until a strictly valid one is obtained (i.e. fgets and
only accepting a 'Y' or an 'N' by itself, ignoring other typed inputs) or
using some other means, the result is the same: attempting to flush the
input buffer.


Ah, yes. I've noticed that problem and some programs that cope with
it. Never thought of it as "flushing" since that has an entirely
different meaning for output. I think Irrwahn's "draining", or
perhaps "clearing", would be better.

I don't see a good way to do it without non-blocking reads. With
them, of course, it's easy.

--
Tom Zych
This email address will expire at some point to thwart spammers.
Permanent address: echo 'g******@cbobk.pbz' | rot13
Nov 13 '05 #23
The Real OS/2 Guy wrote:
stdin is commonly line buffered or unbuffered. In both cases reading
until '\n' is dedected is flushing the input stream. Even when stdin
is set to be block buffered (e.g. as pipe or file it makes sense to
"flush". Because stdin is a text stram, so reading until '\n'
syncronises the stream so that the next coming char will be the first
of a line.


If that's the behavior you want, ok. But another poster pointed out
that one use is to clear the buffer of *all* input, for example, if
the program is asking if you want to do something dangerous. You
wouldn't want it to accept the first character that happens to be in
the input stream in that case.

--
Tom Zych
This email address will expire at some point to thwart spammers.
Permanent address: echo 'g******@cbobk.pbz' | rot13
Nov 13 '05 #24
Kelsey Bjarnason wrote:
The program, realizing that what you asked for is dangerous, puts up a
prompt "Do you really mean this? y/N" and waits for input. However, since
you've already queued up inputs, it may well see an N (or worse, a Y)
and the results range from annoying to disastrous.
<snip>
One frequent solution is to flush input; whether that means reading and
discarding inputs until a strictly valid one is obtained (i.e. fgets and
only accepting a 'Y' or an 'N' by itself, ignoring other typed inputs) or
using some other means, the result is the same: attempting to flush the
input buffer.


Ah, yes. I've noticed that problem and some programs that cope with
it. Never thought of it as "flushing" since that has an entirely
different meaning for output. I think Irrwahn's "draining", or
perhaps "clearing", would be better.

I don't see a good way to do it without non-blocking reads. With
them, of course, it's easy.

--
Tom Zych
This email address will expire at some point to thwart spammers.
Permanent address: echo 'g******@cbobk.pbz' | rot13
Nov 13 '05 #25
The Real OS/2 Guy wrote:
stdin is commonly line buffered or unbuffered. In both cases reading
until '\n' is dedected is flushing the input stream. Even when stdin
is set to be block buffered (e.g. as pipe or file it makes sense to
"flush". Because stdin is a text stram, so reading until '\n'
syncronises the stream so that the next coming char will be the first
of a line.


If that's the behavior you want, ok. But another poster pointed out
that one use is to clear the buffer of *all* input, for example, if
the program is asking if you want to do something dangerous. You
wouldn't want it to accept the first character that happens to be in
the input stream in that case.

--
Tom Zych
This email address will expire at some point to thwart spammers.
Permanent address: echo 'g******@cbobk.pbz' | rot13
Nov 13 '05 #26
Tom Zych wrote:

The Real OS/2 Guy wrote:
stdin is commonly line buffered or unbuffered. In both cases reading
until '\n' is dedected is flushing the input stream. Even when stdin
is set to be block buffered (e.g. as pipe or file it makes sense to
"flush". Because stdin is a text stram, so reading until '\n'
syncronises the stream so that the next coming char will be the first
of a line.


If that's the behavior you want, ok. But another poster pointed out
that one use is to clear the buffer of *all* input, for example, if
the program is asking if you want to do something dangerous. You
wouldn't want it to accept the first character that happens to be in
the input stream in that case.

Don't take this personally, but the point of having an input stream is
to be able to 'read' it. Do that! Determine whether what you read was
dangerous or useful and do the 'wright' thing. It is your program after
all that allows input in the first place. The very least you can do is
'listen' to your user. Having read the input it is always within your
power to ignore it. I see no case for fflush(stdin) or similar.

--
Joe Wright mailto:jo********@earthlink.net
"Everything should be made as simple as possible, but not simpler."
--- Albert Einstein ---
Nov 13 '05 #27
Joe Wright wrote:
Tom Zych wrote:
If that's the behavior you want, ok. But another poster pointed out
that one use is to clear the buffer of *all* input, for example, if
the program is asking if you want to do something dangerous. You
wouldn't want it to accept the first character that happens to be in
the input stream in that case.

Don't take this personally, but the point of having an input stream is
to be able to 'read' it. Do that! Determine whether what you read was
dangerous or useful and do the 'wright' thing. It is your program after
all that allows input in the first place. The very least you can do is
'listen' to your user. Having read the input it is always within your
power to ignore it. I see no case for fflush(stdin) or similar.


I'm not sure you understood me. Did you read Kelsey Bjarnason's
posting?

--
Tom Zych
This email address will expire at some point to thwart spammers.
Permanent address: echo 'g******@cbobk.pbz' | rot13
Nov 13 '05 #28
On Sun, 7 Sep 2003 02:29:50 UTC, Joe Wright <jo********@earthlink.net>
wrote:
Tom Zych wrote:

The Real OS/2 Guy wrote:
stdin is commonly line buffered or unbuffered. In both cases reading
until '\n' is dedected is flushing the input stream. Even when stdin
is set to be block buffered (e.g. as pipe or file it makes sense to
"flush". Because stdin is a text stram, so reading until '\n'
syncronises the stream so that the next coming char will be the first
of a line.


If that's the behavior you want, ok. But another poster pointed out
that one use is to clear the buffer of *all* input, for example, if
the program is asking if you want to do something dangerous. You
wouldn't want it to accept the first character that happens to be in
the input stream in that case.

Don't take this personally, but the point of having an input stream is
to be able to 'read' it. Do that! Determine whether what you read was
dangerous or useful and do the 'wright' thing. It is your program after
all that allows input in the first place. The very least you can do is
'listen' to your user. Having read the input it is always within your
power to ignore it. I see no case for fflush(stdin) or similar.


You gave the wrong answer.

#define EPMPTYIN while (getc() != EOF) ;

will flush the whole stream. If the stream is not a file it will wait
until the user closes it (e.g. Ctrl. C or CTRL D). If it is a file it
would be readed completely.

But in both cases it would be more easy simply to fclose() it.

Flushing an inputstream is commonly used to syncronise the stream to a
point a logical record/field starts. As it is mostenly impossible to
find the next logical field after something wrong comes in it is more
secure to syncronise to the begin of the next record. So reading
anything until '\n' occures means that one has a clean start point
again.

When your stream has another char's words that defined as syncronison
point you may extend the FLUSHIN macro to find them. But as this
exeeds the work

--
Tschau/Bye
Herbert

eComStation 1.1 Deutsch Beta ist verügbar
Nov 13 '05 #29
>On Fri, 05 Sep 2003 02:23:09 +0000, Tom Zych wrote:
Um...what does it mean, to flush an input buffer?

The word "flush" comes from the Middle English "flusshen", meaning
"to take wing" or "to fly up suddenly". (Birds do this in groups
when startled.) This meaning persists today in the phrase "flush
out": things that are hidden can be flushed, chased out of their
concealment for all to see. This is what fflush() does.

Flushing an input buffer, then, would expose its contents to
view -- which is not really all that useful. :-)

I suspect what is really wanted is more like a "purge". The BSDs
have an fpurge() function that does this (for both input AND output,
since it has sensible applications in both cases).

In article <pa****************************@xxnospamyy.lightsp eed.bc.ca>
Kelsey Bjarnason <ke*****@xxnospamyy.lightspeed.bc.ca> writes:You're sitting at the keyboard, firing in commands to do this, that, the
other thing. In the process, you inadvertently enter some option which
is potentially dangerous... but you're still merrily typing away, while
the potentially dangerous program is figuring out what to do - you're
queuing up your inputs.

The program, realizing that what you asked for is dangerous, puts up a
prompt "Do you really mean this? y/N" and waits for input. However, since
you've already queued up inputs, it may well see an N (or worse, a Y)
and the results range from annoying to disastrous.

'Course, if the program had flushed input,
(presumably you mean "purged" input :-) -- but we might simply
redefine "flush" to mean "discard", except when it applies to
output, which is not discarded at all...)
your queued commands would be
lost... but you wouldn't be feeding an unwanted input into the program at
a critical juncture.


There is a technical problem here (with a technical but currently
unimplementable solution). Suppose you are sitting at the keyboard
in Australia, typing into the machine located in Vancouver BC, over
a lossy or satellite-based Internet connection with huge latency.
You are "firing in commands" at time T, T+1, T+2, T+3, and so on,
but the transmission to the remote system is rather "lumpy" so that
they arrive there at time T+2, T+6, T+6, T+6, T+9, T+11, T+11, and
so on.

The "dangerous" operation occurs at time T+5 and arrives at the
remote system at time T+9. By then, of course, even more input is
queued at the source (Australia).

Meanwhile, the program prints "do you really mean this" at T+9 and
tries to purge typeahead. The message "do you really mean this"
arrives in Australia at T+11 or so. What input is discarded?

The problem is that the input, output, and flush/purge/whateveryoucallit
operations are not synchronized -- and without some sort of embedded
timing information (or external protocol), they cannot even *be*
synchronized. So fpurge(), while useful, is still quite limited.
--
In-Real-Life: Chris Torek, Wind River Systems (BSD engineering)
Salt Lake City, UT, USA (40°39.22'N, 111°50.29'W) +1 801 277 2603
email: forget about it http://67.40.109.61/torek/index.html (for the moment)
Reading email is like searching for food in the garbage, thanks to spammers.
Nov 13 '05 #30
Chris Torek wrote:
On Fri, 05 Sep 2003 02:23:09 +0000, Tom Zych wrote:
Um...what does it mean, to flush an input buffer?
I suspect what is really wanted is more like a "purge".


I like the word "drain", for that action.

--
pete
Nov 13 '05 #31

This discussion thread is closed

Replies have been disabled for this discussion.

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.