scanf(), ungetc() behaviour.

[Argento]

I was curious at the start about how ungetc() returns the character to the
stream, so i did the following coding. Things work as expected except if I
change the scanf("%c",&j) to scanf("%d",&j). I don't understand how could
scanf() affect the content of i[0] and i[1]. Can someone tell me why?

#include <stdio.h>
#include <ctype.h>

void main()
{
char i[2], j;
printf("Please input a two digit number:");
i[0]= getchar();
i[1]= getchar();
ungetc(i[1],stdin);
ungetc(i[0],stdin);
scanf("%c", &j); //scanf("%d",&j);
fflush(stdin);
printf("\nYou entered %d in decimal and %c in character mode for
i[0]",i[0],i[0]);
printf("\nYou entered %d in decimal and %c in character mode for
i[1]",i[1],i[1]);
printf("\nYou entered %d in decimal and %c in character mode for j",j,j);

getchar();

}

[Argento]

"CBFalconer " <cb********@yah oo.com> wrote in message
news:44******** *******@yahoo.c om...

Argento wrote:

Publish the instructors email address here and we will collectively
set him/her right. It is not right to warp the minds of the
innocent.
Are you serious about this? Before you answer that first question, I
would just want you to know, those course books are from OUHK
(Open University of Hong Kong, that's where I currently study about
this) taken from the course code MT258.

Yes, I am serious. I don't know what we want to set him right
about, since you snipped that portion. However I vaguely remember
writing the above, although you snipped the attributions. Please
don't do that. I guess snipping is an acquired art.

I am sorry about that. Please accept my apology. As i said in the other
post,
The rules in posting is rather different then those of the newsgroup that i
used
to visit. Guess I still have lots to learn about posting in newsgroup and in
deciding
what to snip. The local newsgroup i used to visit do top-posting, quote the
whole thing,etc.
And I have been reading and learning the rules from what you guys had posted
for the last month. Especially those links about google's broken reply, etc.
I
didn't even know what top posting was at the start :p
We all have an interest in not having bad teachers go uncorrected.
They produce bad product, and make life harder for all of us
correcting those ex-students. Some of us will be more diplomatic
than others, and some will be outright rude.

I suspect if you, as a student, go to your instructor and insist
that he cease and desist from misinformation, it will adversely
affect your marks. However if peers tell him the same, usually
with bell, book, candle, and standards references in hand, s/he may
listen and no evil retribution will fall on you.

Actually not, I had once did that in my U123 course. The instructor hated me
but
fortunately, it didn't affect my mark. They were even teaching HTML &
javascript
wrongly :(

Quoted from :-
http://learn.ouhk.edu.hk/~mt258/mt25...MT258Frame.htm
"The principles used in the Project have been refined and applied to the
development of the course units.
The course units are internally OUHK developed by Dr. Reggie Kwan, a
previous course coordinator
of this course, and Dr. Andrew Lui, the present course coordinator."

And all I have is the present CC's e-mail mt***@learn.ouh k.edu.hk
I hope you'll find it useful.

[Argento]

"Vladimir S. Oka" <no****@btopenw orld.com> wrote in message
news:du******** **@nwrdmz01.dmz .ncs.ea.ibs-infra.bt.com...

Argento wrote:

(You mean fflush(stdin), of course.) Before deciding whether to burn
the book, however, please ensure that it is not merely using them as
examples of common errors to be avoided.

Definitely not. It's used in almost every-little-single code, lol.

Can I watch them burn? ;-)

Only if you are willing to pay part of the cost for buying the book.
It cost me heaps you know. It's course material after all, buying is
compulsory (actually, its accounted into the course fee itself).

[Arndt Jonasson]

ro******@ibd.nr c-cnrc.gc.ca (Walter Roberson) writes:

In article <ln************ @nuthaus.mib.or g>,
Keith Thompson <ks***@mib.or g> wrote:

Arndt Jonasson <do********@inv alid.net> writes:

I prefer using 'return' from main, for about the only reason that I
may otherwise get compilation warnings telling me that the code
between the call to 'exit' and the end of the function is not reached.

Why would you have code between a call to exit and the end of the
function?

I have observed compilers sometimes complain that the implicit return
of a function was not reachable when the function ended with exit()...
even in some very straight forward cases.

Yes, that was the situation I had in mind. Perhaps this reason for
my habit is entirely historical by now.

[Jordan Abel]

On 2006-03-02 23:32:53 -0500, "Argento" <ar********@hot mail.comsaid:

Well, i just keep on seeing examples that uses fflush( stdin ) and i
was told to do so after a scanf() and before a getchar()
because the '\n' is not taken by scanf("%d") or scanf("%c"). That was
my practice of clearing the stdin's buffer.
Any suggestion/alternative of doing so would be appreciated.

Loop getchar() until you see the '\n'.

Though, scanf() itself can be quite capricious and you would do well to
find an alternative to _that_ instead of working around one of its many
apparent and real flaws.

[CBFalconer]

Jordan Abel wrote:

"Argento" <ar********@hot mail.comsaid:

>Well, i just keep on seeing examples that uses fflush( stdin )
and i was told to do so after a scanf() and before a getchar()
because the '\n' is not taken by scanf("%d") or scanf("%c").
That was my practice of clearing the stdin's buffer.
Any suggestion/alternative of doing so would be appreciated.

Loop getchar() until you see the '\n'.

Not good enough. Have the following routine handy:

#include <stdio.h>

int flushln(FILE *f) {
int ch;

while (('\n' != (ch = getc(f))) && (EOF != ch)) continue;
return ch;
}

--
Some informative links:
<news:news.anno unce.newusers
<http://www.geocities.c om/nnqweb/>
<http://www.catb.org/~esr/faqs/smart-questions.html>
<http://www.caliburn.nl/topposting.html >
<http://www.netmeister. org/news/learn2quote.htm l>
<http://cfaj.freeshell. org/google/>

[Richard Heathfield]

CBFalconer said:

Jordan Abel wrote:

>"Argento" <ar********@hot mail.comsaid:

>>Well, i just keep on seeing examples that uses fflush( stdin )
and i was told to do so after a scanf() and before a getchar()
because the '\n' is not taken by scanf("%d") or scanf("%c").
That was my practice of clearing the stdin's buffer.
Any suggestion/alternative of doing so would be appreciated.

Loop getchar() until you see the '\n'.

Not good enough. Have the following routine handy:

#include <stdio.h>

int flushln(FILE *f) {
int ch;

while (('\n' != (ch = getc(f))) && (EOF != ch)) continue;
return ch;
}

Not good enough. Have the following changes ready:

s/flushln/discardln/

(or something along those lines), and either:

s/n ch/n ch == EOF/

or:

s/n ch/n ch != EOF/

The routine is the more useful if its return value can be used in a simple
on/off test in a loop - which you pick is a matter of taste, really. Hence
the second change. The first change is because we really, really, really
mustn't enshrine this ridiculous use of the word "flush" to describe
getting rid of *input*!

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at above domain (but drop the www, obviously)

[Christopher Layne]

Richard Heathfield wrote:

The routine is the more useful if its return value can be used in a simple
on/off test in a loop - which you pick is a matter of taste, really. Hence
the second change. The first change is because we really, really, really
mustn't enshrine this ridiculous use of the word "flush" to describe
getting rid of *input*!

Richard 'discards' his toilet.

[Richard Heathfield]

Christopher Layne said:

Richard Heathfield wrote:

>The routine is the more useful if its return value can be used in a
simple on/off test in a loop - which you pick is a matter of taste,
really. Hence the second change. The first change is because we really,
really, really mustn't enshrine this ridiculous use of the word "flush"
to describe getting rid of *input*!

Richard 'discards' his toilet.

No, Richard regards the contents of the toilet bowl as output, so the word
"flush" is appropriate.

But you don't flush a tap (or, if you are Usanian, a faucet).

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at above domain (but drop the www, obviously)

[CBFalconer]

Richard Heathfield wrote:

Christopher Layne said:

>Richard Heathfield wrote:

>>The routine is the more useful if its return value can be used
in a simple on/off test in a loop - which you pick is a matter
of taste, really. Hence the second change. The first change is
because we really, really, really mustn't enshrine this
ridiculous use of the word "flush" to describe getting rid of
*input*!

Richard 'discards' his toilet.

No, Richard regards the contents of the toilet bowl as output,
so the word "flush" is appropriate.

But you don't flush a tap (or, if you are Usanian, a faucet).

But you do flush an IV. Having had them on and off for the past 3
months I am now an expert.

--
Some informative links:
<news:news.anno unce.newusers
<http://www.geocities.c om/nnqweb/>
<http://www.catb.org/~esr/faqs/smart-questions.html>
<http://www.caliburn.nl/topposting.html >
<http://www.netmeister. org/news/learn2quote.htm l>
<http://cfaj.freeshell. org/google/>

[Richard Heathfield]

CBFalconer said:

Richard Heathfield wrote:

>Christopher Layne said:

>>Richard Heathfield wrote:

The routine is the more useful if its return value can be used
in a simple on/off test in a loop - which you pick is a matter
of taste, really. Hence the second change. The first change is
because we really, really, really mustn't enshrine this
ridiculous use of the word "flush" to describe getting rid of
*input*!

Richard 'discards' his toilet.

No, Richard regards the contents of the toilet bowl as output,
so the word "flush" is appropriate.

But you don't flush a tap (or, if you are Usanian, a faucet).

But you do flush an IV.

Yes, but what does an IV do? It carries a fluid from a reserve store,
through the tube, through the needle, and into the destination storage unit
(known as a "patient"). Thus, flushing an IV - which is done to ensure that
all the fluid intended to be administered has indeed been administered,
just as fflush is done to ensure that all the data we intend to write to
the disk is indeed written - is an *output* operation.

Having had them on and off for the past 3
months I am now an expert.

I am sorry to hear that.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at above domain (but drop the www, obviously)