Date: Thu, 8 Jul 1999 17:15:27 +0300 (IDT)
From: Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
X-Sender: eliz AT is
To: Davin McCall <DavMac AT iname DOT com>
cc: djgpp AT delorie DOT com
Subject: Re: Flushing input stream?
In-Reply-To: <3784268a.526045@newsserver.cc.monash.edu.au>
Message-ID: <Pine.SUN.3.91.990708170650.20318B-100000@is>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Reply-To: djgpp AT delorie DOT com
X-Mailing-List: djgpp AT delorie DOT com
X-Unsubscribes-To: listserv AT delorie DOT com
Precedence: bulk


On Thu, 8 Jul 1999, Davin McCall wrote:

> >It depends on what level do you want to empty the input.  Borland's
> >fflush(stdin) only empties the characters buffered in the stdin FILE
> >object.  This effect can be achieved by calling fseek, like this:
> >
> >  fseek (stdin, -66000, SEEK_CUR);
> >
> >(The magic number 66000 is meant to be larger than any possible size
> >of the so-called transfer buffer used by a DJGPP program to pass data
> >to and from real-mode services.)
> 
> Shouldn't it be positive?

It could be positive, but I didn't test that.  See below.

> That would give the impression of seeking
> "beyond" the end of buffered data, although I suppose a negative
> number would achieve similar results.

The trick is to cause the buffering machinery to invalidate the buffered 
characters.  This can be achieved by an offset that moves the file 
pointer outside the portion of the file that is currently buffered.  So 
both positive and negative offsets should be okay with regular files.

> Is there any reason why you made it negative?

The problem in this particular case is that you fseek on stdin that is 
connected to the console device.  Quick: what does ftell(stdin) return 
for this case?  If you don't know the answer, try a short test program; 
the results might surprise you.

To make the long story short: ftell(stdin) returns huge numbers that go up
all the time.  I preferred to use a negative offset because I didn't
know what happens when the result of ftell overflows 32 bits, and I didn't
have enough time to do a PhD-style research on this small problem.  After
all, nobody pays me to solve problems of others here...