I need help please!

[CBFalconer]

why? Is your first language not english. In uk-english "only
fair" is an idiom for "reasonable"


it is perhaps taken a bit far sometimes. But on the other hand
why use non-portable constructs when portable ones are available?
I suspect you don't know which are which.

Piggybacking. No, it is not taken too far. Without that
limitation we have no idea what other posters are talking about.
With it, there is a common basis. It is always possible to explain
things by including the necessary code, unless that code is
non-standard, or too large.

 

[Walter Roberson]

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".

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".


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.

Notice that last quoted sentance, "fflush has no effect on an
unbuffered stream". 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?

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.

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.

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?" 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'" ?

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.)

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.)


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).

 

[Nick Keighley]

I see [Bill Reid] is clairvoyant in that he has deduced that the regulars are
incapable of actually writing code.  After all, if you are concerned
about correctness, then you can't possibly create anything useful

yeah I noticed that

 

[Bill Reid]

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?

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?").

 

[Eric Sosman]

[...]
> "Is it possible to write a totally 'portable'
function that will consume ALL the characters left in the standard input
regardless of platform?"

Yes, barring I/O errors that disrupt the flow of control.

#include <stdio.h>
void eat_stdin(void) {
for (;;getchar());
}

 

[Bill Reid]

[...]
"Is it possible to write a totally 'portable'
function that will consume ALL the characters left in the standard input
regardless of platform?"

Yes, barring I/O errors that disrupt the flow of control.

#include <stdio.h>
void eat_stdin(void) {
for (;;getchar());
}

Exactly, some code to that effect, I thought everybody knew this...so
why is it news to all the other posters to this thread but you and me?

 

[Eric Sosman]

[...]
"Is it possible to write a totally 'portable'
function that will consume ALL the characters left in the standard input
regardless of platform?"

Yes, barring I/O errors that disrupt the flow of control.

#include <stdio.h>
void eat_stdin(void) {
for (;;getchar());
}

Exactly, some code to that effect, I thought everybody knew this...so
why is it news to all the other posters to this thread but you and me?

Do you know of Raymond Smullyan's recipe for immortality?
You need only do two things to guarantee yourself eternal
life: (1) always tell the truth, and (2) utter the words
"I will repeat this sentence tomorrow."

My solution to the problem you posed is as correct as
Smullyan's recipe -- and equally useful. It solves the problem
you stated, while demonstrating that solving it is useless.
Didn't you notice that little drawback?

"Be careful what you ask for" may be the most important
maxim of the programmer's trade.

 

[santosh]

[...]
"Is it possible to write a totally 'portable'
function that will consume ALL the characters left in the standard
input regardless of platform?"

Yes, barring I/O errors that disrupt the flow of control.

#include <stdio.h>
void eat_stdin(void) {
for (;;getchar());
}

Exactly, some code to that effect, I thought everybody knew this...so
why is it news to all the other posters to this thread but you and me?

How can you "clear" stdin without blocking? All you can do is read upto
a '\n' character, and that too only when you know for *sure* that the
stdin buffer is *not* empty.

 

[muntyan]

[...]

"Is it possible to write a totally 'portable'

function that will consume ALL the characters left in the standard input
regardless of platform?"

Yes, barring I/O errors that disrupt the flow of control.

#include <stdio.h>
void eat_stdin(void) {
for (;;getchar());
}

The following is simpler and doesn't require an extra #include:

void eat_stdin(void)
{
for (; ;
}

 

[Ben Pfaff]

The following is simpler and doesn't require an extra #include:

void eat_stdin(void)
{
for (; ;
}

But it doesn't accomplish the goal.

 

[santosh]

But it doesn't accomplish the goal.

They are both joking.

 

[Flash Gordon]

[...]
"Is it possible to write a totally 'portable'

function that will consume ALL the characters left in the standard input
regardless of platform?"

Yes, barring I/O errors that disrupt the flow of control.

#include <stdio.h>
void eat_stdin(void) {
for (;;getchar());
}

The following is simpler and doesn't require an extra #include:

void eat_stdin(void)
{
for (; ;
}

However it does not meet the specification as it does not eat the input
from stdin. On a system which does not have a way to throw away output
but which has the ability to redirect the output of one program to
another the following program inspired by Eric's function could be useful:

#include <stdio.h>
#include <stdio.h>
int main(void)
{
while (getchar()>=0);
return ferror(stdin)?EXIT_FAILURE:0;
}

 

[santosh]

Bill Reid wrote:
[...]
"Is it possible to write a totally 'portable'

function that will consume ALL the characters left in the standard
input regardless of platform?"
Yes, barring I/O errors that disrupt the flow of control.

#include <stdio.h>
void eat_stdin(void) {
for (;;getchar());
}

The following is simpler and doesn't require an extra #include:

void eat_stdin(void)
{
for (; ;
}

However it does not meet the specification as it does not eat the
input from stdin.

They were both joking.

 

[user923005]

But it doesn't accomplish the goal.

As you know, these sorts of things are often system specific. The
defect is obvious. Under Windows, it is important to make sure that
the process gets enough time slices:

#include <windows.h>
#include <stdio.h>

void eat_stdin(void)
{
for (;{;}
}

int main(void)
{
if (!SetThreadPriority(GetCurrentThread(),
THREAD_PRIORITY_TIME_CRITICAL)) {
puts("Tragic failure setting priority class.");
exit(EXIT_FAILURE);
}
eat_stdin();
return 0;
}

Under Linux, we might accomplish the same sort of thing with:
err = pthread_attr_setschedpolicy(&threadAttributes, SCHED_RR);

It's very important under these circumstances that nothing interrupts
our important task. Otherwise, even more characters might escape from
the keyboard and climb all the way to the stdin stream (a distance
that can exceed one meter!).

 

[Bill Reid]

Bill Reid wrote:
[...]
"Is it possible to write a totally 'portable'
function that will consume ALL the characters left in the standard input
regardless of platform?"
Yes, barring I/O errors that disrupt the flow of control.

#include <stdio.h>
void eat_stdin(void) {
for (;;getchar());
}

Exactly, some code to that effect, I thought everybody knew this...so
why is it news to all the other posters to this thread but you and me?

Do you know of Raymond Smullyan's recipe for immortality?

No, but I did read "The Zero With A Million Names" and have in
this case pondered the "sound of one troll yapping"...

How about we start REAL slow...I don't know how good you are
at programming and computers and stuff, but here is the fragment
that set off "troll zero":

if(yn_input[string_size-1]!='\n') {

fflush(stdin);
goto ReTry;
}

Which is an effective work-alike to:

if(yn_input[string_size-1]!='\n') {

while(getchar()!='\n') ;
goto ReTry;
}

Will that work, or is it too "platform-specific"?

You need only do two things to guarantee yourself eternal
life: (1) always tell the truth, and (2) utter the words
"I will repeat this sentence tomorrow."

My solution to the problem you posed is as correct as
Smullyan's recipe -- and equally useful. It solves the problem
you stated, while demonstrating that solving it is useless.

Might as well give up then, and the Sun is going to burn out
anyway, so let's just troll Usenet till we die!

Didn't you notice that little drawback?

Excuses, excuses...

"Be careful what you ask for" may be the most important
maxim of the programmer's trade.

First quote I ever heard from a "professional" programmer was
"obscurity is job security". Ever hear THAT one? I HAVE found
that programmers are like cops...there's never one around when
you need one...and they both like free doughnuts...

 

[Flash Gordon]

Bill Reid wrote, On 12/03/08 01:54:

Bill Reid wrote:
[...]
"Is it possible to write a totally 'portable'
function that will consume ALL the characters left in the standard input
regardless of platform?"
Yes, barring I/O errors that disrupt the flow of control.

#include <stdio.h>
void eat_stdin(void) {
for (;;getchar());
}
Exactly, some code to that effect, I thought everybody knew this...so
why is it news to all the other posters to this thread but you and me?

If you know how to do the job correctly in one line then you have even
less excuse for posting a non-portable solution.

No, but I did read "The Zero With A Million Names" and have in
this case pondered the "sound of one troll yapping"...

How about we start REAL slow...I don't know how good you are
at programming and computers and stuff, but here is the fragment
that set off "troll zero":

What I've seen suggests that Eric knows a lot more about programming and
computers than you.

if(yn_input[string_size-1]!='\n') {

fflush(stdin);
goto ReTry;
}

Which is an effective work-alike to:

if(yn_input[string_size-1]!='\n') {

while(getchar()!='\n') ;
goto ReTry;
}

Will that work, or is it too "platform-specific"?

Well, the second case definitely won't flush everything from the input
buffers for standard input on some systems (the buffers, which include
OS buffers, could have more than one line in it on some systems under
some conditions), but it is more likely to meet the real requirements
rather than the stated objective of flushing the buffer.

Of course, you really need to check for input failure in case standard
input is being piped in from a file or it is a remote shell and the
network connection drops or someone absent mindedly (or deliberately)
presses control-Z or...

while ((c=getchar())!='\n' && c!=EOF) continue;
if (c==EOF) exit(EXIT_FAILURE); /* or whatever you want on failure */

Without seing the original code I would also suspect that the use of
goto was needlessly messy. Retry loops always seem like a perfect case
for the use of a loop to me.

Might as well give up then, and the Sun is going to burn out
anyway, so let's just troll Usenet till we die!


Excuses, excuses...

Ah, so you did not notice the drawback.

First quote I ever heard from a "professional" programmer was
"obscurity is job security". Ever hear THAT one?

Yes, but only from people who were joking, trolling or insulting.

I HAVE found
that programmers are like cops...there's never one around when
you need one...and they both like free doughnuts...

Ever heard that stereotypes are generally both insulting and wrong?

 

[santosh]

Do you know of Raymond Smullyan's recipe for immortality?

No, but I did read "The Zero With A Million Names" and have in
this case pondered the "sound of one troll yapping"...

How about we start REAL slow...I don't know how good you are
at programming and computers and stuff, but here is the fragment
that set off "troll zero":

if(yn_input[string_size-1]!='\n') {

fflush(stdin);
goto ReTry;
}

Which is an effective work-alike to:

if(yn_input[string_size-1]!='\n') {

while(getchar()!='\n') ;
goto ReTry;
}

No. fflush(stdin), if implemented as common sense suggests, will clear
the streams end-of-file and error markers too. It will, most
importantly, not block if there are no pending input characters.
getchar won't do both of this.

Will that work, or is it too "platform-specific"?

The first one platform specific, the second one will not always work as
expected.

<snip>

 

[Eric Sosman]

How about we start REAL slow...I don't know how good you are
at programming and computers and stuff, but here is the fragment
that set off "troll zero":

if(yn_input[string_size-1]!='\n') {

fflush(stdin);
goto ReTry;
}

Okay. This code is broken, so broken there's a FAQ
explaining its brokenness. Pointing out the breakage is
a favor to the person who contemplates using the broken
code, not any species of trollery.

Which is an effective work-alike to:

"Effective?" What's "effective" about it? It's
broken, broke, breaked, busted, and bogus.

if(yn_input[string_size-1]!='\n') {

while(getchar()!='\n') ;
goto ReTry;
}

Will that work, or is it too "platform-specific"?

Not sure which fragment you intend "that" to mean,
nor what exactly you mean by "work." I see nothing
platform-specific about the second fragment. It's
wrong, but not in a platform-specific way; it might
be described as "portably wrong."

 

[Bill Reid]

Do you know of Raymond Smullyan's recipe for immortality?

No, but I did read "The Zero With A Million Names" and have in
this case pondered the "sound of one troll yapping"...

How about we start REAL slow...I don't know how good you are
at programming and computers and stuff, but here is the fragment
that set off "troll zero":

if(yn_input[string_size-1]!='\n') {

fflush(stdin);
goto ReTry;
}

Which is an effective work-alike to:

if(yn_input[string_size-1]!='\n') {

while(getchar()!='\n') ;
goto ReTry;
}

No. fflush(stdin), if implemented as common sense suggests, will clear
the streams end-of-file and error markers too. It will, most
importantly, not block if there are no pending input characters.
getchar won't do both of this.

BWHAHAHAHAHAHAHAHAHAHA!!!

You guys just kill me! First you complain about fflush(stdin), then
you promote its undocumented and "non-standard" use based on a
reliance that it works as "common sense suggests"!

Congrats, you just earned triple bonus troll points!!!

The first one platform specific, the second one will not always work as
expected.

To be fair I should have included just a little more of the original
code (to be really fair, I shouldn't be required to re-post the original
code at all just because a bunch of trolls snipped it as their first
act of trollery):

fgets(yn_input,sizeof(yn_input),stdin);

string_size=strlen(yn_input);

if(yn_input[string_size-1]!='\n') {
fflush(stdin);
goto ReTry;
}

So you're saying that if we substitute "while(getchar()!='\n') ;" for
fflush(stdin) above, it won't "always work as expected"...OK, maybe
that's a little more troll-defensible than "troll-zero"'s statement
that "fgets() is very likely to fail under some circumstances" when
the "circumstances are reading from the standard input...

....but it's still a troll. Yay, more troll points for you!

 

[Bill Reid]

Bill Reid wrote, On 12/03/08 01:54:

Bill Reid wrote:
Bill Reid wrote:
[...]
"Is it possible to write a totally 'portable'
function that will consume ALL the characters left in the standard input
regardless of platform?"
Yes, barring I/O errors that disrupt the flow of control.

#include <stdio.h>
void eat_stdin(void) {
for (;;getchar());
}
Exactly, some code to that effect, I thought everybody knew this...so
why is it news to all the other posters to this thread but you and me?

If you know how to do the job correctly in one line then you have even
less excuse for posting a non-portable solution.

You trolls really need to coordinate your efforts better...you've got
about three different and mutually exclusive threads of insane troll
logic going here...the above is the "joke troll", and another troll is
now actually ENDORSING fflush(stdin)!!!

What I've seen suggests that Eric knows a lot more about programming and
computers than you.

Well, probably, but since you and all the other trolls seem to be
completely befuddled by what is essentially just one step up from
a "hello world" program I'm not sure how to evaluate your actual
worth to society...there's not much practical difference between
playing dumb and being dumb, you know...

if(yn_input[string_size-1]!='\n') {

fflush(stdin);
goto ReTry;
}

Which is an effective work-alike to:

if(yn_input[string_size-1]!='\n') {

while(getchar()!='\n') ;
goto ReTry;
}

Will that work, or is it too "platform-specific"?

Well, the second case definitely won't flush everything from the input
buffers for standard input on some systems (the buffers, which include
OS buffers, could have more than one line in it on some systems under
some conditions), but it is more likely to meet the real requirements
rather than the stated objective of flushing the buffer.

Well, semantics again, a real problem that I'm willing to let slide,
I wasn't talking about flushing a "buffer", just getting rid of any
unconsumed
characters input by the user. If I don't do that, I get a gigantic mess
when I prompt the user to "retry" because the next fgets() just gets
all those unwanted fat-finger characters and the whole thing just
repeats itself needlessly...I woulda thunk that this simple user input
requirement would be obvious and could be coded by a PROFICIENT
C programmer in their sleep (for me, I did it many years ago and
I think it took about two hours to get it right, but I'm an idiot and
NOT a programmer), but then I posted it here, and inane insanity
ensued...

Of course, you really need to check for input failure in case standard
input is being piped in from a file or it is a remote shell and the
network connection drops or someone absent mindedly (or deliberately)
presses control-Z or...

Yeah, I don't do that stuff, so it's not a requirement, and most all of
that stuff is just more bogus trolling AGAIN...

while ((c=getchar())!='\n' && c!=EOF) continue;
if (c==EOF) exit(EXIT_FAILURE); /* or whatever you want on failure */

OK, I'll take it under "advisement"...you really think that "EOF"
checking is a good idea?

Without seing the original code I would also suspect that the use of
goto was needlessly messy. Retry loops always seem like a perfect case
for the use of a loop to me.

What'd I say a few posts ago? IT NEVER ENDS!!! As soon as I
fixed all the other non-existent "problems", another troll would pop
up and complain about the "goto"s!!! ARRRRRRRRGHGHHHH!!!!

Ah, so you did not notice the drawback.

What drawback?

Yes, but only from people who were joking, trolling or insulting.

So you HAVE heard it! AHA!!!

Ever heard that stereotypes are generally both insulting and wrong?

I think it is very unfair of you to characterize stereotypes that way...but
I've already acknowledged that I've met several extremely productive and
knowledgeable engineers in my time, but what do they say about the
exceptions that prove the rule?