I need help please!

[santosh]

A library routine must try to deal sensibly with all reasonable
possibilities. CTRL-D is often used to signal end of input, or as a
wish to exit from the program. That is another option that you should
try to present, wherever it makes sense: allowing a user to exit the
application without having to kill it with CTRL-C or 'kill'.

Well, my "user" is me, and me alone, [ ... ]

Yes, but the point it you posted it for public consumption, so it is
only fair of you to point out places in your code where you invoke
behaviour not guaranteed by the Standard.

as I've said many times, and
I know exactly how and when to exit the application (as a matter of
fact, generally you are offered the option to "abort" in all menus,
which is usually a RETURN default that bumps you back to a previous
level menu, so press RETURN about three or four times tops and you're
done)...

Fine, but I couldn't know this could I? Your posted code did not show
this option.

so MY library deals with all MY reasonable possibilities, so
it's "golden" by your "standard"...

In short, the routine works for ME...for others, a few tweaks may be
in order...

Exactly. And once such tweak the hapless newbie might have to do is to
comment out your fflush(stdin) line. But since you don't mention it's
non-portability in the code, the newbie is likely to waste his time and
shed a few hairs trying to figure out why the code doesn't work like
it's author said it should.

<snip>

 

[Flash Gordon]

Bill Reid wrote, On 09/03/08 01:32:

OK, THINK REAL HARD...I know this might be tough, but try...

YOU WANT TO "TRY" TO "GRACEFULLY" QUIT THE
PROGRAM BY PRESSING AN UNDOCUMENTED KEY
COMBINATION ABSENT-MINDEDLY, BUT YOU'RE WORRIED

It is documented on some systems I've use a lot as a standard way of
exiting at any point.

ABOUT FAILURE TO GET A 'y' OR 'n' INPUT?

DOES THAT MAKE ANY SENSE? How about your untimely

<snip>

Any software written for general consumption should deal with unexpected
keystrokes for the simple reason that, in the real world, they are very
common.

Next time you MIGHT try just reading the documentation (I know, that
doesn't ALWAYS work, but it's still the REASONABLE man's method
of discovering information about a system)...beats hitting the "any" key
to "test" stuff, anyway...

The point is that you claim that fflush(stdin) just works is wrong. The
documentation would not have proved it as it does not mention flushing
input streams, so I tested to enable me to state with certainty that it
does not work. So you "REASONABLE man's method" fails on a very common
system, namely Linux on an x86. I would say that a "solution" that does
not work on a very common platform is NOT a reasonable solution.

No, "snippy", people who use uncalled-for abusive and insulting
language to harass people who post well-meaning information are
trolls, but you "snipped" out the troll's nastiness for reasons known

OK, so you are a troll by your definition. That clears that up.

only to you...CONSTRUCTIVE criticism is ALWAYS welcome, but

So in your opinion any criticism of your posts is not constuctive, but
posting bad advice is a good thing. Well, since you meet your definition
of a troll this is not surprising.

please try to keep your disappointment down to a dull roar if I merely
point out that I've previously considered the point you've made and
rejected it on purely practical grounds for my purposes...

Simple enough?

So you want your software to rely on undefined behaviour that does not
do what you expect on common platforms. The simple solution is to keep
such software to yourself since it is not suitable for posting as advice
and when you post it people will keep pointing out the problems with it.

 

[Morris Dovey]

I've expressed skepticism that many of the "regulars" here have
ever written any reasonable amount of practical working computer
code, based strictly on my knowledge of the behavior patterns of
unproductive people. In short, unproductive people ALWAYS hide
behind what I call the "wall of repugnance", which is divert attention
from their failure to produce by attacking the productive people
around them incessantly. I believe the natural way that "troll
zero" falls into baseless personal attacks in this and most threads
belies his overall "strategy" for "coping" with the pressures of
competing in the "real world"...

Hmm. I don't think you've made an effort substantiate those
remarks. I consider myself a "lesser" regular in that I find
myself professionally obliged to "look up to" the others. For a
look at the _bottom_ of the spectrum, you're invited to look over

http://www.iedu.com/mrd/mrd_res1.html

 

[Bill Reid]

Bill Reid wrote, On 09/03/08 01:32:

It is documented on some systems I've use a lot as a standard way of
exiting at any point.


<snip>

Any software written for general consumption should deal with unexpected
keystrokes for the simple reason that, in the real world, they are very
common.

OK, I'll just go over this for about the FOURTH time:

MY software is not written for "general consumption", only for ME.

Also, I as a computer user don't generally spastically start computer
programs, only to abort them using the wrong character sequence for
that system when confronted by a simple yes/no prompt. I will admit
that I have used CNTRL-z (or less frequently CNTRL-c) in the past
when dealing with software that I didn't understand that seemed
to be running on forever in a seemingly endless loop, but AGAIN,
I DID THAT BECAUSE I JUST WANTED THE PROGRAM TO
DISAPPEAR, REGARDLESS OF THE CONSEQUENCES.
I have not and do not do it a lot because quite simply I was not
dropped on my head as a baby so I have at least decent computer
user skills if not endless programming skills...

AGAIN, you have been explicitly offered multiple chances to
make the simple correction to the code in question to accomodate
YOUR idiotic computer usage style, but as a Usenet troll in good
standing you continue to just abusively GRIPE ABOUT OTHER
PEOPLE'S WORK AND ARGUE without doing anything even
remotely CONSTRUCTIVE, which I am sure must be a "lifestyle"
for you and not just a mere temporary Usenet persona...

As far as my own system goes, pressing CNTRL-z DELIBERATELY
will indeed sort of mess up the library function and particularly the
"user experience", though not always fatally. CNTRL-c actually
kills the program with a SIGINT no matter what (I know not and care
little how "gracefully" the default handler does this, for the reasons
above). Any other CNTRL-key combination (except CNTRL-ALT-DELETE)
results in extended characters being displayed and consumed and
the routine deals with them as with any other incorrect input.

I can mash my hands down on the keyboard clumsily, all over the
keyboard, no problem. I can put my feet on the keyboard, no problem.
I can put the keyboard upside-down on the floor and step on it, no
problem.

So to sum up, there actually IS such a thing as "user error", which
is a user that is so insanely stupid and deliberately malicious they
should be prevented from even touching a computer, and YOU'RE
THAT USER, and I'm not writing software for somebody as stupid
as you...sorry, maybe PlaySkool(TM) has some applications that
would be more appropriate for your intellectual and emotional age...

Well, at least this example of "troll zero"'s NON-CONSTRUCTIVE and
POINTLESS personal attacks made it through the "snip factory"...

The point is that you claim that fflush(stdin) just works is wrong.

I works for me. That's MY real life. Just because it doesn't work
for you doesn't impact MY real life. This is particularly true because
even if it DID work for you, as a troll in good standing you'd be
duty-bound to point out that it MIGHT not work for some people,
EVEN AFTER BEING TOLD REPEATEDLY THAT NOT EVERYTHING
IN THE CODE WAS "PORTABLE". This is the same insane troll
logic that caused you to find the single idiotic key sequence that
MIGHT cause an unintended result (sort of) in a user input routine.

The
documentation would not have proved it as it does not mention flushing
input streams, so I tested to enable me to state with certainty that it
does not work.

Well, yeah, my "documentation" for fflush() actually does NOT
mention anything about input streams, and in fact is the usual
mush-mouthed bad tech writing that is found for almost all the
"man pages". But buried in an obscure and almost inaccessible
section of the documentation called something like "Special
Extensions", they let slip the "secret" that fflush(stdin) can be
used to clear the input stream...so my theory is a guy (or gal)
MUCH smarter and more productive than you wrote the
documentation, because it merely sucks, but unlike your
contributions to the planet, it does EXIST...

So you "REASONABLE man's method" fails on a very common
system, namely Linux on an x86. I would say that a "solution" that does
not work on a very common platform is NOT a reasonable solution.

Hey, you can make a good argument that a REASONABLE man
does not run Linux on an x86 in the first place! But congratulations,
calling it a "very common platform" should further up your status as
an insane useless troll...this is almost as good as "troll zero" saying
that fgets() on the standard input will "very likely fail under some
circumstances", which as you've so ably demonstrated, "very likely"
is about 0.000000000000001% probable unless due to deliberate
insane troll misuse of the computer!

OK, so you are a troll by your definition. That clears that up.

Wrong. "Troll zero" did NOT post well-meaning information, but
several insults based on what you have now proven are statistical
and technical lies. But that's just what insane trolls do, and when
somebody points out that they're insane trolls, they acheive the
ultimate troll "victory" by screaming "I am rubber, you are glue!"
like a toddler with a dirty bottom...

So in your opinion any criticism of your posts is not constuctive,

That's just a lie from an insane troll. I've stated my "opinion" (it's
written in plain English above), and that was not it. AGAIN (this is
pointless, because insane trolls NEVER give up), "troll zero" engaged
in a series of ad hominen attacks based on statistical and technical lies,
for no other purpose than being a "troll" in the full meaning of that term.
You engage in the same behavior. How's that working out for you?

but
posting bad advice is a good thing.

"Bad advice" can always be corrected and/or qualified without
provocative ad hominen attacks. In this case, and in so many
of the cases in this particular group that is apparently run by
insane trolls, it doesn't matter if it is "good advice" or "bad advice"
or "mediocre advice", every well-meaning informational post
with functioning practical code is just a target for the insane
trolls...however, the actual quality of the advice DOES ratchet
up the hysterical lengths that the insane trolls will go to
attack it...

Well, since you meet your definition
of a troll this is not surprising.

AGAIN, my definition of a troll can be found in your mirror...

So you want your software to rely on undefined behaviour that does not
do what you expect on common platforms.

What'd I say about insane trolls? THEY NEVER GIVE UP!!! They
live in their own little insane troll world where x86 Linux is a "common
platform" and practical working code on the most common platform
of all is "undefined behavio(u)r"!!! WHAT A "LIFESTYLE"!!!

The simple solution is to keep
such software to yourself since it is not suitable for posting as advice
and when you post it people will keep pointing out the problems with it.

Hey, somebody's gotta write some code in this world, since your
only contribution to the planet is to be an insane troll, so I'll just keep
writing it and posting it and you can keep acting like a troll and that's
apparently just "the way things are"...good luck!

 

[Bill Reid]

A library routine must try to deal sensibly with all reasonable
possibilities. CTRL-D is often used to signal end of input, or as a
wish to exit from the program. That is another option that you should
try to present, wherever it makes sense: allowing a user to exit the
application without having to kill it with CTRL-C or 'kill'.

Well, my "user" is me, and me alone, [ ... ]

Yes, but the point it you posted it for public consumption, so it is
only fair of you to point out places in your code where you invoke
behaviour not guaranteed by the Standard.

And I just plain disagree with your notion of "fair". For that matter,
I just plain disagree with the silly notion presented quite often here
about the ostensible charter of the group, that it must slavishly only
and anal-retentively discuss "standard" C, and then only a down-rev
standard, not the latest one!

There I said it, and not for the first time, and I have VERY good
(and "fair", and PRACTICAL) reasons for saying it. If you disagree,
well, it's your prerogative to be wrong...occasionally, it even happens
to me!

In the instant case, I noted generally that a lot of stuff in the code
was "non-portable", and as a PRACTICAL matter I don't think it is
"fair" to waste people's time requiring them to document every single
unseen macro definition, compiler extension, etc., because it's
not just MY time you're wasting, you're also wasting the valuable
learning time of all those "newbies" you're so worried about.

In the "real world", any non-trivial quality C code is ALWAYS
"non-portable" because at the least it relies heavily on non-"standard"
libraries, INCLUDING in many cases "portability" libraries that
deal with platform dependencies, or in the case of code that is
intended to be used on a single platform, correctly and PRACTICALLY
uses specific platform system calls and "extensions".

It's never too early for the "newbies" to learn that valuable lesson
CORRECTLY, and the technically inaccurate and misleading
personal attacks that the trolls who infest this group post whenever
the topic of C programming is actually attempted to be discussed
IS NOT AT ALL HELPFUL in clarifying the true nature of the topic.

Fine, but I couldn't know this could I? Your posted code did not show
this option.

You also didn't know what "DEF_YES", "DEF_NO", "YES", "NO",
etc., etc., etc., meant either. There's all kinds of stuff you "don't
know", but as a PRACTICAL matter why should I have to document
every single aspect of my applications, libraries, etc., just to share
some simple code that speeds development time, reduces redundant
coding, and prevents program crashes due to the typical "fat-finger"
user error for ME (which is exactly ALL I claimed for it, not that it met
with some abusive troll's fantasy requirements for "correct" coding)?

Exactly. And once such tweak the hapless newbie might have to do is to
comment out your fflush(stdin) line. But since you don't mention it's
non-portability in the code, the newbie is likely to waste his time and
shed a few hairs trying to figure out why the code doesn't work like
it's author said it should.

Once again, there was NO misreprentation on my part as to the
"portability" of the code. And the sooner the "newbie" learns that
valuable lesson, the quicker they won't be a "newbie" any more.

The problem here is that most of the regulars have NEVER learned
that lesson, so they are technically and intellecually unable to "help"
ANYBODY, and they further compound it by lashing out with abusive
personal attacks based on technical and statistical inaccuracies
that just make it even more confusing than it already is...and
THAT'S not "fair"...

 

[Bill Reid]

No, the majority of educated users in this group KNOW that some
things are not guaranteed by the C standard, and thus should be
avoided. They find that the simple action of using the library and
language correctly ensures the portability of their code. They are
extremely lazy,

Don't forget stupid and creepy!

and do not eagerly anticipate rewriting all their
code at every port.

I've expressed skepticism that many of the "regulars" here have
ever written any reasonable amount of practical working computer
code, based strictly on my knowledge of the behavior patterns of
unproductive people. In short, unproductive people ALWAYS hide
behind what I call the "wall of repugnance", which is divert attention
from their failure to produce by attacking the productive people
around them incessantly. I believe the natural way that "troll
zero" falls into baseless personal attacks in this and most threads
belies his overall "strategy" for "coping" with the pressures of
competing in the "real world"...

In short, I don't believe that most of the "regulars" here have any
real amount of code to "port" (and of course, no particular reason
to "port" it in the first place), because in the "real world" you can
either be a griper or a producer, and most here are just gripers!

You are lucky enough to get their analysis without charge. If you
choose to ignore it, that's your loss.

Responding to trolls is always a loss, living a world with trolls is
a nuisance, but part of life...I just accept it and do the best I can
with the world as it is, "wisdom to change the things I can", yadda,
yadda...

But insulting those helpful
and knowledgeable people tends to get you ignored.

Well, then don't do it! I personally NEVER insult HELPFUL
and KNOWLEDGEABLE people, and you shouldn't either, even
if it gains you "troll points"!

But you know, I believe that "troll zero" actually claimed I
was in his "kill-file" at some point, which would be GREAT
for me, but after years of dealing with the over-the-borderline
personality disorders that infect Usenet in its dying days I know
that the more a troll threatens to or claims to "kill-file" a poster,
the more they obsessively read and attack, and maybe progess
to "stalking" the poster.

So I should guess I should just consider myself "lucky enough"
that I have such thoughtful and helpful (and correct!) analysis as
was given to me by "troll zero", because if I was even "luckier",
the abusive useless freak might start crank-calling me or
park outside my house!

 

[Bill Reid]

The compiler has little to do with it, it works with any compiler on a
platform where the operation is defined and fails with any platform
where its isn't.

Really? So all the code I've seen that chew up unused characters
in the standard input would still fail based on a platform technicality?

And on the other hand, doesn't the compiler have to do something
specific (and specifically DIFFERENT) to accomodate a call to
fflush() with "stdin" as the stream? For that matter, isn't the "standard"
that fflush() only works at all on buffered streams?

Such platform specific code is pretty common (I know I've used
fflush(stdin) on Solaris), but is should be noted, or even conditionally
compiled as a hint for maintainers. The maintainer might be you
porting your own code to a new platform.

Sure, for "professional" developers it would be a "courtesy" (read:
"should be a job requirement"), but that's not my situation...however
in my experience in software development that stuff would be
handled by the existing portability libraries anyway, and as I said
the call would be to something like "clear_input()" or some other
way of transparently dealing with differing platforms...

 

[Ian Collins]

Really? So all the code I've seen that chew up unused characters
in the standard input would still fail based on a platform technicality?

It's the fact that it does compile that makes fflush(stdin), like many
other instances of undefined behaviour, cause a feeding frenzy when
anyone posts them.

And on the other hand, doesn't the compiler have to do something
specific (and specifically DIFFERENT) to accomodate a call to
fflush() with "stdin" as the stream? For that matter, isn't the "standard"
that fflush() only works at all on buffered streams?

All the compiler sees is a FILE*. The problem occurs at run time, not
compile time.
Your signature should start with "-- "

 

[santosh]

Bill Reid wrote:

<snip long discussion>

Okay, it seems we can agree to disagree. I think it's important that
constructs depending on undefined behaviour must be documented in the
code and in any accompanying documentation, particularly if the code is
meant for wide consumption, or is meant to be generic.

I agree that non-portable code is often necessary, so I don't know why
you are so strenuously belabouring that point. I disagree that
Linux/x86 is an unimportant platform and I resent your obtuse
statements on the intelligence of Linux/x86 users.

That about sums it up. HAND.

 

[Flash Gordon]

Bill Reid wrote, On 09/03/08 17:47:

OK, I'll just go over this for about the FOURTH time:

MY software is not written for "general consumption", only for ME.

<snip>

Then don't post it for general consumption. Keep it to yourself rather
than showing people bad examples.

 

[Bill Reid]

It's the fact that it does compile that makes fflush(stdin), like many
other instances of undefined behaviour, cause a feeding frenzy when
anyone posts them.

For a second there, I thought I was about to learn something, but
now I'm even more confused...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?"

Frankly, I think I've heard it both ways...

All the compiler sees is a FILE*. The problem occurs at run time, not
compile time.

Well, sure, but by "compiler" I am actually referring (imprecisely perhaps)
to the fflush() "standard" library function, which at run-time then must
then "do something" in accordance with the standard, or maybe could
do a little extra-curricular "undefined behavior" that is actually useful
and
wanted with "stdin" as the FILE *...you seem to be implying that if a
system call doesn't exist to clear the standard input, it CAN'T happen,
and if such a call DOES exist, it will ALWAYS happen, and both
possibilities are outside the control of the compiler writer...and frankly,
I just don't get that...

Your signature should start with "-- "

Oh, good point!

 

[Bill Reid]

Hmm. I don't think you've made an effort substantiate those
remarks.

I've spent my entire adult life substantiating those remarks! Unless
you're talking about any specific individual or set of individuals, the
general principle applies: people who gripe about other people and
gripe about life in general usually are not productive team members.

When given a task, they return almost immediately with dozens
of excuses and complaints about why the task cannot be accomplished,
and most of these complaints are about their fellow workers who, when
you examine their actual working relationships, you find that there
are little to no "gating dependancies" between them, but rather they
seem to choose "victims" based on a combination of their threatening
compentency and dedicated quiet application of their talents to
acheive productive results.

I've worked with some of the best engineers on the planet, and again
GENERALLY the "superstars" are FALSELY described as "brittle",
"uncommunicative", not "team players", "mean-spirited", etc., by their
so-called "peers", and yet I can rarely find even a shred of actual
observed behavior to support these accusations, only amazingly
productive high-quality output. Conversely, the "fakes" can quickly
be predicted by their incessant personal attacks on their "victims",
only to be confirmed after wrestling them down to ANY kind of
commitment, and having them fail to accomplish even the simplest
of job duty...

I consider myself a "lesser" regular in that I find
myself professionally obliged to "look up to" the others. For a
look at the _bottom_ of the spectrum, you're invited to look over

http://www.iedu.com/mrd/mrd_res1.html

I've seen the best and the worst, so I have no need to look. I will
grant you that some people are just not qualified to perform a job,
but even worse are people who seek to destroy the ability of others
to do their jobs. I've watched entire $billion companies destroyed
when the "fakes" took over the "democratic process" from weak
and ineffectual management...

 

[Bill Reid]

Bill Reid wrote, On 09/03/08 17:47:



<snip>

Then don't post it for general consumption. Keep it to yourself rather
than showing people bad examples.

Sorry, can't help you out with your "problem"...it won't be often, it
won't be much (compared to the "regulars"), but if I feel like it I will
participate helpfully and maturely on Usenet, and any time YOU
want to do the same, feel free. Otherwise, don't have a thrombo,
baby...I know I can't get rid of the trolls and spammers on Usenet,
so I don't worry much about it, so likewise you shouldn't worry about
the rare adult who occasionally posts here...

 

[Ian Collins]

For a second there, I thought I was about to learn something, but
now I'm even more confused...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?"

Considering your original question was badly phrased and appears to bear
no resemblance to the one you just asked, no wonder you are confused.

The answer to this question is maybe. I've never had cause to try.

The standard clearly states:

"If stream points to an output stream or an update stream in which the
most recent operation was not input, the fflush function causes any
unwritten data for that stream to be delivered to the host environment
to be written to the file; otherwise, the behavior is undefined."

 

[Morris Dovey]

I've spent my entire adult life substantiating those remarks! Unless
you're talking about any specific individual or set of individuals, the
general principle applies: people who gripe about other people and
gripe about life in general usually are not productive team members.

I was speaking about the particular set of individuals you named
in the very first line I quoted. It appears to me that you did
the very thing your words decry.

 

[CBFalconer]

Hmm. I don't think you've made an effort substantiate those
remarks. I consider myself a "lesser" regular in that I find
myself professionally obliged to "look up to" the others. For a
look at the _bottom_ of the spectrum, you're invited to look over

He obviously hasn't bothered to look at the published available
code from his criticizers. However it doesn't seem to matter much
any more, now that we have resolved his accuracy and gotten around
to plonking him. Hopefully there are enough non-plonkers to emit
the much needed future corrections.

 

[Antoninus Twink]

He obviously hasn't bothered to look at the published available
code from his criticizers. However it doesn't seem to matter much
any more, now that we have resolved his accuracy and gotten around
to plonking him.

Is that the royal "we"?

(Hint: even your former friends in The Clique have turned against you as
your opinions become ever more absurd)

And fix your damn signature.

 

[Nick Keighley]

A library routine must try to deal sensibly with all reasonable
possibilities. CTRL-D is often used to signal end of input, or as a
wish to exit from the program. That is another option that you should
try to present, wherever it makes sense: allowing a user to exit the
application without having to kill it with CTRL-C or 'kill'.
Well, my "user" is me, and me alone, [ ... ]

not once you've posted it and described it as a general purpose
library.
(though I have to confess I rarely check for errors from fgets())

And I just plain disagree with your notion of "fair".

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

 For that matter,
I just plain disagree with the silly notion presented quite often here
about the ostensible charter of the group, that it must slavishly only
and anal-retentively discuss "standard" C, and then only a down-rev
standard, not the latest one!

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.

There I said it, and not for the first time, and I have VERY good
(and "fair", and PRACTICAL) reasons for saying it.  If you disagree,
well, it's your prerogative to be wrong...occasionally, it even happens
to me!

but you seem incapable of stating your good, fair and practical
reasons.
Note ALL UPPER CASE and lots of !! don't substitute for reasoned
arguement

In the instant case, I noted generally that a lot of stuff in the code
was "non-portable", and as a PRACTICAL matter I don't think it is
"fair" to waste people's time requiring them to document every single
unseen macro definition, compiler extension, etc., because it's
not just MY time you're wasting, you're also wasting the valuable
learning time of all those "newbies" you're so worried about.

In the "real world", any non-trivial quality C code is ALWAYS
"non-portable" because at the least it relies heavily on non-"standard"
libraries, INCLUDING in many cases "portability" libraries that
deal with platform dependencies, or in the case of code that is
intended to be used on a single platform, correctly and PRACTICALLY
uses specific platform system calls and "extensions".

It's never too early for the "newbies" to learn that valuable lesson
CORRECTLY,

but you aren't teaching the lesson, you're encouraging him to
ignore it!

and the technically inaccurate and misleading
personal attacks that the trolls who infest this group post whenever
the topic of C programming is actually attempted to be discussed
IS NOT AT ALL HELPFUL in clarifying the true nature of the topic.



You also didn't know what "DEF_YES", "DEF_NO", "YES", "NO",
etc., etc., etc., meant either.  There's all kinds of stuff you "don't
know", but as a PRACTICAL matter why should I have to document
every single aspect of my applications, libraries, etc., just to share
some simple code that speeds development time, reduces redundant
coding, and prevents program crashes due to the typical "fat-finger"
user error for ME (which is exactly ALL I claimed for it, not that it met
with some abusive troll's fantasy requirements for "correct" coding)?

have you ever been to a code review?

Once again, there was NO misreprentation on my part as to the
"portability" of the code.  And the sooner the "newbie" learns that
valuabe lesson, the quicker they won't be a "newbie" any more.

but he *won't* learn it from your code because you don't document the
unportable bits!

The problem here is that most of the regulars have NEVER learned
that lesson,

what lesson?

so they are technically and intellecually unable to "help"
ANYBODY, and they further compound it by lashing out with abusive
personal attacks based on technical and statistical inaccuracies
that just make it even more confusing than it already is...and
THAT'S not "fair"...

boo hoo. Gently encouraging people to write more portable code is a
good thing. Some code has to work on more than one platform and
last more than a week. Presumably you've never seen code
break over endianess or alignment when it was ported.

It is good programming practice to write portable code when you can.
And to confine the non-portable code to limited well documented
modules.

Using fflush(stdin) is just plain dumb.

 

[Nick Keighley]

what's a "platform technicality"? If, say, Microsoft, docuements that
fflush(stdin)
discards all the characters buffered on the stdin stream ***in
Microsofts implementation***
then you can pretty well assume that's what it does do. You may have
to read more
documentation to find out what "buffered" means. And worry about
network disks
and sockets and so on.


no. What does "left in" mean?

Considering your original question was badly phrased and appears to bear
no resemblance to the one you just asked, no wonder you are confused.

The answer to this question is maybe.  I've never had cause to try.

The standard clearly states:

"If stream points to an output stream or an update stream in which the
most recent operation was not input, the fflush function causes any
unwritten data for that stream to be delivered to the host environment
to be written to the file; otherwise, the behavior is undefined."

in other words fflush(stdin) is not defined. The C standard does not
define the behaviour hence the implementor is free to do whatever
he pleases. Or at least whatever he thinks is reasonable.

Possibilities
- discard contents of stdin buffer
- ignore the call
- abort()

 

[user923005]

what's a "platform technicality"? If, say, Microsoft, docuements that
fflush(stdin)
discards all the characters buffered on the stdin stream ***in
Microsofts implementation***
then you can pretty well assume that's what it does do. You may have
to read more
documentation to find out what "buffered" means. And worry about
network disks
and sockets and so on.


no. What does "left in" mean?





in other words fflush(stdin) is not defined. The C standard does not
define the behaviour hence the implementor is free to do whatever
he pleases. Or at least whatever he thinks is reasonable.

Possibilities
- discard contents of stdin buffer
- ignore the call
- abort()

He obviously hasn't bothered to read the FAQ before posting:

12.26a: How can I flush pending input so that a user's typeahead isn't
read at the next prompt? Will fflush(stdin) work?

A: fflush() is defined only for output streams. Since its
definition of "flush" is to complete the writing of buffered
characters (not to discard them), discarding unread input
would
not be an analogous meaning for fflush on input streams.
See also question 12.26b.

References: ISO Sec. 7.9.5.2; H&S Sec. 15.2.

12.26b: If fflush() won't work, what can I use to flush input?

A: It depends on what you're trying to do. If you're trying to
get
rid of an unread newline or other unexpected input after
calling
scanf() (see questions 12.18a-12.19), you really need to
rewrite
or replace the call to scanf() (see question 12.20).
Alternatively, you can consume the rest of a partially-read
line
with a simple code fragment like

while((c = getchar()) != '\n' && c != EOF)
/* discard */ ;

(You may also be able to use the curses flushinp() function.)

There is no standard way to discard unread characters from a
stdio input stream, nor would such a way necessarily be
sufficient, since unread characters can also accumulate in
other, OS-level input buffers. If you're trying to actively
discard typed-ahead input (perhaps in anticipation of issuing
a
critical prompt), you'll have to use a system-specific
technique; see questions 19.1 and 19.2.

References: ISO Sec. 7.9.5.2; H&S Sec. 15.2.

At any rate, we are forced to ask the question:
"If fflush(stdin) were to discard characters from the input stream,
why is it that they were present in the first place ... and are we
sure that they are unwanted?"

In short, fflush(stdin) makes no sense, even if it is defined as an
extension.
I suspect that the O.P. is a pure troll, but it is hard to say for
sure from just a few messages. We'll find out in a day or two.
I see he 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.