«

hugo 27, Oct 9, 2004

Ref Docs: c.l.c FAQ article 12.26 .
www.digitalmars.com sitemap.stdio.fflush

Reading these Docs I understand that fflush does not
summarily destroy or discard the flushed data.
But it is not clear, in the case of fflush(stdin),
where stdin is default C keyboard buffer, what
actually becomes of the data.
Is there a way to capture it?

fflush( ) returns an int as status report, so one
cannot assign fflush's return to char str[20], for
insatance. Does this function take a second argument?
like fflush(stdin, str);
?
hugo

"hugo27" <> wrote
>
> But it is not clear, in the case of fflush(stdin),
> where stdin is default C keyboard buffer, what
> actually becomes of the data.
> Is there a way to capture it?
>
You flush a toilet (out) not a tap (in).

fflush(stdin) is an error in ANSI C. The implementation can treat it anyhow,
including irreversibly losing the contents of the input buffer.

[snips]

On Sat, 09 Oct 2004 13:47:46 -0700, hugo27 wrote:

> But it is not clear, in the case of fflush(stdin),
> where stdin is default C keyboard buffer, what
> actually becomes of the data.

Since fflush is defined only for output streams, and stdin is an input
stream, fflush(stdin) is undefined behaviour. Thus, to answer your
question, "what actually becomes of the data?" the answer is: anything
whatsoever can happen to it.

On 9 Oct 2004 13:47:46 -0700, in comp.lang.c , (hugo27)
wrote:

>But it is not clear, in the case of fflush(stdin),
>where stdin is default C keyboard buffer, what
>actually becomes of the data.

You can't fflush(stdin) so the question is meaningless. See 12.26 of the
FAQ.

>Is there a way to capture it?

Yes. Don't try to flush the stream, but instead read the stream, storing
the data, till you have emptied it.

>fflush( ) returns an int as status report, so one
>cannot assign fflush's return to char str[20],

Well, no, for fflush forces anything in the stream to be written. How would
it be meaningful to return the data?

>Does this function take a second argument?
> like fflush(stdin, str);

The question makes no sense as you can't flush input streams and anyway
fflush() forces the data to be written to the stream. Since you put the
data in teh stream, you have no need for a copy....

--
Mark McIntyre
CLC FAQ <http://www.eskimo.com/~scs/C-faq/top.html>
CLC readme: <http://www.ungerhu.com/jxh/clc.welcome.txt>


----== Posted via Newsfeed.Com - Unlimited-Uncensored-Secure Usenet News==----
http://www.newsfeed.com The #1 Newsgroup Service in the World! >100,000 Newsgroups
---= 19 East/West-Coast Specialized Servers - Total Privacy via Encryption =---

In some situations, stdin refers to the same file as stdout or stderr,
so you could end up flushing these (no real harm done).

Eg. On linux console, by default: stdin, stdout and stderr all refer
to the current console.

Although I don't know much about the standards, I'm guessing undefined
behaviour here. If stdin refers to a file that can be written to, you
would flush whatever has been to this file. If stdin is input-only
(you have to assume this to be portable), then its undefined
behaviour.

Hope this clarifys things,
Paul Barker

In article <news: om>
Paul Barker <> wrote:
>Eg. On linux console, by default: stdin, stdout and stderr all refer
>to the current console.

But it will not matter there, because:

>Although I don't know much about the standards, I'm guessing undefined
>behaviour here.

The C standard leaves it undefined. This allows other systems to
impose behavior upon it, if they choose.

The POSIX standard says that fflush() on an input-mode stream has
the effect of synchronizing the lseek() offset on the underlying
file descriptor (which only matters for regular files, not devices),
without doing any other "flushing". A call to fflush(stdin) must
therefore NOT discard ANY data.

>If stdin refers to a file that can be written to, you
>would flush whatever has been to this file.

This is not right (but not wrong either, it just makes no sense at
all): the fflush() operation will inspect the stdio stream, see
that the stream is in "read" mode, and lseek() the underlying file
descriptor, which may or may not be shared with other processes'
file descriptor(s) for the same underlying file. (The only reason
to do this kind of lseek() call is if it *is* in fact shared,
in particular after a POSIX fork().) The call will not even attempt
to find other stdio streams that might refer to the same file,
especially since they are most likely to be inside another process
entirely, and thus unreachable.
--
In-Real-Life: Chris Torek, Wind River Systems
Salt Lake City, UT, USA (40°39.22'N, 111°50.29'W) +1 801 277 2603
email: forget about it http://web.torek.net/torek/index.html
Reading email is like searching for food in the garbage, thanks to spammers.