By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
458,182 Members | 1,430 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 458,182 IT Pros & Developers. It's quick & easy.

new line character : scanf and getchar

P: n/a
char c;
int i;

scanf("%d",&i);
c=getchar();

I want to read a integer and a character in 2 lines.
Why the getchar always get the \n character from the last line?????

(Sorry for my newbie question, but where is the FAQ section of the
newsgroup??)
Nov 14 '05 #1
Share this Question
Share on Google+
11 Replies


P: n/a
j

"Mars" <Mars@Mars> wrote in message news:41**********@rain.i-cable.com...
char c;
int i;

scanf("%d",&i);
c=getchar();

I want to read a integer and a character in 2 lines.
Why the getchar always get the \n character from the last line?????

In your case, stdin refers to an interactive device and as such, is line
buffered.
This means that data is transferred when a newline is encountered.

If scanf's conversion succeeds you will have a newline left in your input
stream.
Any subsequent read issued on stdin will encounter this newline if you did
not enter additional data after some integer that corresponds to your
conversion
specifier.

One solution would be,

void consume_stdin(void)
{
while((getchar()) != '\n')
;
}
You should also do some error checking with respect to scanf's return value.
(Sorry for my newbie question, but where is the FAQ section of the
newsgroup??)


http://www.eskimo.com/~scs/C-faq/faq.html

--
j
Nov 14 '05 #2

P: n/a
Why don't you just write

int i;
char c;

scanf("%d",&i);
fflush(stdin); //flushes the input stream and gets rid of '\n'
character
c=getchar();

Try it out, it will work.

Nov 14 '05 #3

P: n/a
j

"Sontu" <ab******@gmail.com> wrote in message
news:11**********************@c13g2000cwb.googlegr oups.com...
Why don't you just write

int i;
char c;

scanf("%d",&i);
fflush(stdin); //flushes the input stream and gets rid of '\n'
character
c=getchar();

Try it out, it will work.


Supposing that there is data in the input stream, where do you propose
that it will be flushed to?

This is actually addressed in the FAQ but I want you to answer my question.

--
j
Nov 14 '05 #4

P: n/a
"Sontu" <ab******@gmail.com> wrote:
Why don't you just write
Why doesn't _who_ just write that? Leave in some context when you post!
If you must use Google-broken-beta, learn to use it properly.
int i;
char c;

scanf("%d",&i);
fflush(stdin); //flushes the input stream and gets rid of '\n'
Because the behaviour fflush() is undefined for input streams. It only
works for output streams.
Try it out, it will work.


Says you. On your edition of your favourite compiler, it may even do
something. It's not required to do anything sane or safe, though.

Richard
Nov 14 '05 #5

P: n/a
Sontu wrote:

Why don't you just write

int i;
char c;

scanf("%d",&i);
fflush(stdin); //flushes the input stream and gets rid of '\n'
character
c=getchar();

Try it out, it will work.


No it won't (portably). It may assasinate somebody. Please don't
give incorrect advice around here. You should have looked up the
validity of fflush for input devices (which is none).

--
"If you want to post a followup via groups.google.com, don't use
the broken "Reply" link at the bottom of the article. Click on
"show options" at the top of the article, then click on the
"Reply" at the bottom of the article headers." - Keith Thompson
Nov 14 '05 #6

P: n/a
Mars <Mars@Mars> writes:
char c;
int i;

scanf("%d",&i);
c=getchar();

I want to read a integer and a character in 2 lines.
Why the getchar always get the \n character from the last line?????


The getchar() reads the '\n' character because the scanf() didn't read it.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.
Nov 14 '05 #7

P: n/a
j wrote:
"Mars" <Mars@Mars> wrote:
char c;
int i;

scanf("%d",&i);
c=getchar();

I want to read a integer and a character in 2 lines.
Why the getchar always get the \n character from the last line?????

In your case, stdin refers to an interactive device and as
such, is line buffered. This means that data is transferred
when a newline is encountered.


Irrelevent, the same problem occurs on any stream. All you can
deduce from this is that there was a newline character after
the number.
Exactly the same thing would have happened if stdin was coming
from a non-interactive device (eg. a file), so I don't know
how you can say that it did refer to an interactive device.
If scanf's conversion succeeds you will have a newline left in
your input stream.
Any subsequent read issued on stdin will encounter this newline
if you did not enter additional data after some integer that
corresponds to your conversion specifier.


Subsequent reading will always encounter the newline (eventually).
(I think this is what you intended to say, although on the first
reading, it seemed to me that you were saying that if additional
data was entered then the newline would not be encountered).

Nov 14 '05 #8

P: n/a
j

"Old Wolf" <ol*****@inspire.net.nz> wrote in message
news:11**********************@f14g2000cwb.googlegr oups.com...
j wrote:
"Mars" <Mars@Mars> wrote:
char c;
int i;

scanf("%d",&i);
c=getchar();

I want to read a integer and a character in 2 lines.
Why the getchar always get the \n character from the last line?????


In your case, stdin refers to an interactive device and as
such, is line buffered. This means that data is transferred
when a newline is encountered.


Irrelevent, the same problem occurs on any stream. All you can
deduce from this is that there was a newline character after
the number.
Exactly the same thing would have happened if stdin was coming
from a non-interactive device (eg. a file), so I don't know
how you can say that it did refer to an interactive device.


Yeah, I'm not sure what I was thinking there.
If scanf's conversion succeeds you will have a newline left in
your input stream.
Any subsequent read issued on stdin will encounter this newline
if you did not enter additional data after some integer that
corresponds to your conversion specifier.


Subsequent reading will always encounter the newline (eventually).
(I think this is what you intended to say, although on the first
reading, it seemed to me that you were saying that if additional
data was entered then the newline would not be encountered).


I was thinking in terms of what he presented.
He just included one call to getchar after scanf.

Something such as ``10aaaaaa\n''
would have yielded a valid conversion
with a subsequent read producing ``a''.

--
j
Nov 14 '05 #9

P: n/a
T O


Old Wolf wrote:
j wrote:
"Mars" <Mars@Mars> wrote:
char c;
int i;

scanf("%d",&i);
c=getchar();

I want to read a integer and a character in 2 lines.
Why the getchar always get the \n character from the last line?????


In your case, stdin refers to an interactive device and as
such, is line buffered. This means that data is transferred
when a newline is encountered.

Irrelevent, the same problem occurs on any stream. All you can
deduce from this is that there was a newline character after
the number.
Exactly the same thing would have happened if stdin was coming
from a non-interactive device (eg. a file), so I don't know
how you can say that it did refer to an interactive device.

If scanf's conversion succeeds you will have a newline left in
your input stream.
Any subsequent read issued on stdin will encounter this newline
if you did not enter additional data after some integer that
corresponds to your conversion specifier.

Subsequent reading will always encounter the newline (eventually).
(I think this is what you intended to say, although on the first
reading, it seemed to me that you were saying that if additional
data was entered then the newline would not be encountered).


Taking this a step further then, what would be a good but simple method
of reading a single character from stdin, evaluating that character (if
c=="Y") for example, and then flushing all buffers.
Is there a simple way to achieve a yes/no response without requring a CR
from the user, thereby presumably negating this problem of /n.
Nov 14 '05 #10

P: n/a
T O <TO> writes:
[...]
Taking this a step further then, what would be a good but simple
method of reading a single character from stdin, evaluating that
character (if c=="Y") for example, and then flushing all buffers.
Is there a simple way to achieve a yes/no response without requring a
CR from the user, thereby presumably negating this problem of /n.


C FAQ 19.1: "How can I read a single character from the keyboard
without waiting for the RETURN key? How can I stop characters from
being echoed on the screen as they're typed?"

<http://www.eskimo.com/~scs/C-faq/q19.1.html>

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.
Nov 14 '05 #11

P: n/a
T O wrote:
.... snip ...
Taking this a step further then, what would be a good but simple
method of reading a single character from stdin, evaluating that
character (if c=="Y") for example, and then flushing all buffers.
You could call the following function:

/* Returns EOF for file ended, else '\n' */
int flushln(FILE *f)
{
int ch;

while ((EOF != (ch = getc(f))) && ('\n' != ch)) continue;
return ch;
} /* flushln */
Is there a simple way to achieve a yes/no response without requring a CR
from the user, thereby presumably negating this problem of /n.


No. Without input line buffering there would be no input line
editing, which would be a much bigger nuisance than requiring a
<cr>.

--
"If you want to post a followup via groups.google.com, don't use
the broken "Reply" link at the bottom of the article. Click on
"show options" at the top of the article, then click on the
"Reply" at the bottom of the article headers." - Keith Thompson
Nov 14 '05 #12

This discussion thread is closed

Replies have been disabled for this discussion.