Re: I need help please!


Hey, this guy is pretty good, a little less troll-y, a little more
informational, and most importantly of all, he actually posts from
a REAL newsreader that actually attributes each poster unlike
the fools who only know how (or can afford?) to post from Google(TM)
Groups that makes it pain in the ass to reply to their messages,
but the messages are just lame trolls anyway, so why waste the
time?

Walter Roberson <roberson@xxxxxxxxxxxxxxxxxx> wrote in message
news:fr4djc$9lg$1@xxxxxxxxxxxxxxxxxxxxxxxxxx
In article <F8ZAj.293776$MJ6.142737@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx>,
Bill Reid <hormelfree@xxxxxxxxxxxxxxxx> wrote:

you didn't answer the question I asked,
which, to put it another way, "Is it possible to write a totally
'portable'
function that will consume ALL the characters left in the standard input
regardless of platform?"

It depends on what you mean by "consume ALL the characters left in
the standard input".

A loop that reads characters until EOF satisfies the criteria from
for at least one meaning of "the characters left in the standard input".

Well, yeah, I'm not asking for miracles here...and considering that
such code is simple, obvious, and well-known, I'm wondering why all
the trolls here have such amazing ignorance of it but still proclaim
"standard-doublespeak" and proudly post that "if a platform supports
it, it can be done"...

If, though, you mean "all of the characters which have 'arrived'
but not yet been consumed by the program, leaving the stream
intact and able to read characters that 'arrive' 'later'",
then the answer is, of course, "No, there is no portable way to
do that; it is not possible on some platforms".

IBID

You might, by the way, be interested to note that fflush(stdin) on MS
Windows does *not* have the above-mentioned hypothetical effect:

http://msdn2.microsoft.com/en-us/library/9yky46tz(VS.71).aspx

The fflush function flushes a stream. If the file associated with
stream is open for output, fflush writes to that file the contents
of the buffer associated with the stream. If the stream is open for
input, fflush clears the contents of the buffer. fflush negates the
effect of any prior call to ungetc against stream. Also,
fflush(NULL) flushes all streams opened for output. The stream
remains open after the call. fflush has no effect on an
unbuffered stream.

Yeah, I knew all this, just wanted to see if anybody else did!

Notice that last quoted sentance, "fflush has no effect on an
unbuffered stream".

Yup, I brought this up previously, seemed to just confuse all the
trolls here...like so many technical questions, they were unable to
answer it, so they just did a little name-calling and called it a post...

For an explanation of this behavior, refer to my description of
the "wall of repugnance" that unskilled and unproductive people
use to conceal their inadequacies...

From this we deduce that fflush(stdin) would
have no effect (and thus not the effect of flushing) if stdin
is unbuffered. But is stdin buffered or unbuffered?

According to the documentation for my development package,
only if it is "redirected", or a buffer is specifically associated with
it!

C89 4.9.5.3 The fopen Function
When opened, a stream is fully buffered if and only if it
can be determined not to refer to an interactive device.

However, the Microsoft description of fopen does not have any
language corresponding to that,

http://msdn2.microsoft.com/en-us/library/yeby3zcb(VS.71).aspx

If one happens to look in the MS section about 'Stream I/O (CRT)',

http://msdn2.microsoft.com/en-us/library/c565h7xx(VS.71).aspx

Files opened using the stream routines are buffered by default.

Hmmmm, appears to be a "discrepancy" here, who woulda
thunk it...

No exception is made there for stdin, even though the previous
paragraph specifically refers to "the console (keyboard and screen)".
Of course each operating system is free to define what is an
"interactive device", (C89 2.1.2.3 "What constitutes an interactive
device is implementation-defined") and if Microsoft chooses to define
"the console (keyboard and screen)" (and -every- other kind of device)
as not being an "interactive device", then we don't really have anything
to say about the matter. It isn't exactly intuitive, but it is
legal in C89, and we have now firmly established that in MS Win32
applications, stdin is buffered (unless it has been changed to
unbuffered by specific program action), so there is meaning in
MS's fflush() documentation for there to be a "buffer" associated
with stdin that fflush() could clear.

Yippee!

Now, how big is the MS stdin buffer? Looking at the same 'Stream I/O'
URL cited above, we see,

The default size of a stream buffer is 4K.

Thus unless settings were changed, in MS Win32, fflush(stdin)
will flush the remainder of a 4K buffer.

We would do well to ask "What, the -entire- buffer? Or only to
the end of the line?"

This is getting dangerously close to "troll zero"'s original
assertion that "fgets() is very likely to fail under some circumstances".

Which of course, is deliberate troll-doublespeak, equivalent to
"it is very likely that you will be struck by lightning three times
in 15 minutes while simultaneously being eaten by a shark
ON LAND under SOME circumstances"...when asked what
those "circumstances" were, "troll zero" bugged out and left
it to "troll-ettes" to make hypocritical fools of themselves
by tying us to a lightning rod, deliberately seeding thunderclouds
with mercury iodide, covering us in cow blood, and placing
a starving Great White Shark at our ankles...

To resolve this we turn to MS's setvbuf
documentation:

http://msdn2.microsoft.com/en-us/library/86cebhfs(VS.71).aspx

_IOFBF
Full buffering; that is, buffer is used as the buffer and size
is used as the size of the buffer. If buffer is NULL, an
automatically allocated buffer size bytes long is used.
_IOLBF
For some systems, this provides line buffering. However, for
Win32, the behavior is the same as _IOFBF - Full Buffering.

So... Win32, line buffering is the same as full buffering, so
Yes, it would be the rest of the buffer, not just the rest of the
line.

After all of this, why do I say that MS's fflush(stdin) does not
meet the hypothetical (but psychologically reasonable) standard,
of flushing "all of the characters which have 'arrived'
but not yet been consumed by the program, leaving the stream
intact and able to read characters that 'arrive' 'later'" ?

You're an obsessive completist?

To see this, go back a small number of paragraphs: the default buffer
size for stdin for MS Win32 is 4Kb, and according to the MS fflush()
documentation, it is only that buffer which is flushed, *not* "all of
the characters which have 'arrived' but not yet been consumed by the
program". If more than 4Kb has "arrived" (e.g., a large copy and
paste) then only at most 4Kb of it will be flushed; anything remaining
will still be hanging around (even if only in the output buffers
of a program such as the Windows Desktop, waiting for input to
be consumed so that it can deliver the rest of the data.)

This is why you gotta love Usenet; remember folks, the code
I posted was trying to get a 'y' or 'n' response, and I was actually
using an (unseen) FOUR-CHARACTER array to store the input
of fgets(), which, if it could be over-filled by the user, I egregiously
used fflush(stdin) to get rid of the excess characters NOT CONSUMED
by fgets()...and then the HIGHLY-productive trolls ("productive" at
being trolls) showed up, and here we are, days later! Nobody's
gettin' ANYTHING done, and that's the way they like it!

What else might not be in the buffer that gets flushed? There is also
the possibility of data that has arrived at a serial or parallel port
or USB port but which has not yet made it through the interrupt
sequence, or which has not yet been DMA'd from the lower layers to the
process input buffer: that data has "arrived" but if it hasn't reached
the process input buffer yet then it will not be flushed by
fflush(stdin) in MS Win32. Similarily, there is the possibility of
network packets that are being processed through the network layers and
haven't made it into the process input buffer yet: the content of the
packets will not be flushed either. (Flushing them before they nearly
reach the process input buffer would lead to important questions about
what data should be ACK'd, if it was a TCP connection or other protocol
that used reliable packet delivery.)

Broadcast messages on UNIX systems might screw up the "user
experience" of my get_yn_input() as well...because of this, I've decided
to destroy my computer and return to performing spreadsheets and
all other numeric and database operations manually using pencil
and paper and filing cabinets...

So... I would suggest that, at the very least, the question you
posed needs to be rephrased in rather tighter technical terms --
one that does -not- devolve down to *defining* "consuming input"
as that which MS Windows does upon fflush(stdin).

Problem is, in the context of the code I posted, my question
was clear to anybody who is able to quickly and effectively handle
technical issues and produce workable computer code...my real
problem is that I posted it in the wrong group, since this whole
thread is just another example that the ONE thing you can't do
here is talk about C programming (remember, "troll zero" once
freaked out because I posted COMPLETELY standard C code
with a subject title of "Is there something wrong with this code?").

---
William Ernest Reid



.