scanf doubt

[deepak]

Hi,

For the program pasted below, scanf is not waiting for the second user
input.
Can someone suggest reason for this?

void
main()
{
char c;

scanf("%c", &c);
printf("%c\n", c);

scanf("%c", &c);
printf("%c\n", c);

return(TRUE);
}

output:
a
a

[Jens Thoms Toerring]

deepak <de*********@gm ail.comwrote:

For the program pasted below, scanf is not waiting for the second user
input.
Can someone suggest reason for this?

You're missing

#include <stdio.h>

void
main()

make that

int main( void )

especially since your main() function returns a value.

{
char c;

scanf("%c", &c);
printf("%c\n", c);

Here you read a single char which then gets printed out.

scanf("%c", &c);
printf("%c\n", c);

And here you read a second char that also gets printed out.
It's just that this char is the char for the <ENTERkey,
'\n', which you don't see directly. So your program actually
reads in two chars, just that the second isn't one you were
expecting.

return(TRUE);

What's 'TRUE'? Better return either 0 (which always indicates
success) or either EXIT_SUCCESS or EXIT_FAILURE as defined in
<stdlib.h>.

}

Regards, Jens
--
\ Jens Thoms Toerring ___ [e-mail]
\______________ ____________ http://toerring.de

[Daniel Molina Wegener]

On Aug 13, 9:46 am, deepak <deepakpj...@gm ail.comwrote:

Hi,

For the program pasted below, scanf is not waiting for the second user
input.
Can someone suggest reason for this?

The buffer isn't flushed?, apply fflush(3) over stdin.
Also, scanf to get chars from the user input isn't safe,
try getc(3) over stdin.

>
void
main()
{
char c;

scanf("%c", &c);
printf("%c\n", c);

scanf("%c", &c);
printf("%c\n", c);

return(TRUE);

}

output:
a
a

Regards,
DMW

[Jens Thoms Toerring]

Daniel Molina Wegener <dm*@coder.clwr ote:

On Aug 13, 9:46 am, deepak <deepakpj...@gm ail.comwrote:

Hi,

For the program pasted below, scanf is not waiting for the second user
input.
Can someone suggest reason for this?

The buffer isn't flushed?, apply fflush(3) over stdin.

fflush() can only be used for output streams, using it
for input is a Windows extension which doesn't work on
other systems.

Also, scanf to get chars from the user input isn't safe,
try getc(3) over stdin.

What's unsafe about scanf() when reading in chars the
user did input? A different question would be if it
would be more effective to use getc(), fgetc() or
getchar() when reading just single chars...

Regards, Jens
--
\ Jens Thoms Toerring ___ [e-mail]
\______________ ____________ http://toerring.de

[vippstar]

On Aug 13, 6:52 pm, j...@toerring.d e (Jens Thoms Toerring) wrote:

Daniel Molina Wegener <[e-mail] rote:

<snip>

The buffer isn't flushed?, apply fflush(3) over stdin.

fflush() can only be used for output streams, using it
for input is a Windows extension which doesn't work on
other systems.

It's not an extension, it's undefined behavior.

Also, scanf to get chars from the user input isn't safe,
try getc(3) over stdin.

It's certainly safe.

[Daniel Molina Wegener]

On Aug 13, 11:52 am, j...@toerring.d e (Jens Thoms Toerring) wrote:

Daniel Molina Wegener <[e-mail] rote:

On Aug 13, 9:46 am, deepak <deepakpj...@gm ail.comwrote:

Hi,

For the program pasted below, scanf is not waiting for the second user
input.
Can someone suggest reason for this?

The buffer isn't flushed?, apply fflush(3) over stdin.

fflush() can only be used for output streams, using it
for input is a Windows extension which doesn't work on
other systems.

Thanks, I will take a better read on manual pages next
time.

>

Also, scanf to get chars from the user input isn't safe,
try getc(3) over stdin.

What's unsafe about scanf() when reading in chars the
user did input? A different question would be if it
would be more effective to use getc(), fgetc() or
getchar() when reading just single chars...

Thanks again, "effective" is the right word...

>
Regards, Jens
--
\ Jens Thoms Toerring ___ j...@toerring.d e
\______________ ____________ http://toerring.de

Regards,
DMW

[Keith Thompson]

deepak <de*********@gm ail.comwrites:

For the program pasted below, scanf is not waiting for the second user
input.
Can someone suggest reason for this?

void
main()
{
char c;

scanf("%c", &c);
printf("%c\n", c);

scanf("%c", &c);
printf("%c\n", c);

return(TRUE);
}

output:
a
a

Jens already explained the problem; the second scanf is reading
the new-line. You're seeing 'a' twice in your output because the
first is echoed when you typed it, and the second is the result
of the printf call. You're probably seeing an extra blank line on
output as well.

Try typing "ab" without hitting the enter key after the 'a'.
Then read section 12 of the comp.lang.c FAQ, <http://www.c-faq.com/>.
Then read the rest of it.

I don't believe that the code you posted is your real code.
It should have been rejected by your compiler. You left out the
"#include <stdio.h>" that's required for scanf and printf, and you
incorrectly declared main to return void rather than int, but you
could probably get away with both of those errors. The more serious
problems are attempting to return a value from a void function,
which should have produced at least a warning, and referring to
TRUE without declaring it, which should have caused your program
to be rejected.

If you're going to post code here, please post the *exact* code that
you actually compiled. Copy-and-paste it; don't re-type it. If you
got any diagnostic messages from the compiler, either warnings or
error messages, show us those as well (again, copy-and-paste the
messages; don't re-type them or try to summarize them.)

The exact details are important. If you knew which information you
could safely omit, you'd know enough that you wouldn't need to ask
your question in the first place.

--
Keith Thompson (The_Other_Keit h) ks***@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[Keith Thompson]

vi******@gmail. com writes:

On Aug 13, 6:52 pm, j...@toerring.d e (Jens Thoms Toerring) wrote:

>Daniel Molina Wegener <[e-mail] rote:

<snip>

The buffer isn't flushed?, apply fflush(3) over stdin.

fflush() can only be used for output streams, using it
for input is a Windows extension which doesn't work on
other systems.

It's not an extension, it's undefined behavior.

An implementation may define the behavior of a construct whose
behavior is not defined by the C standard. That's a valid way to
provide an extension.

But whether you call it an extension or UB, it's certainly
non-portable (and, in this particular case, unnecessary).

[...]

--
Keith Thompson (The_Other_Keit h) ks***@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[vippstar]

On Aug 13, 7:58 pm, Keith Thompson <[e-mail] rote:

vipps...@gmail. com writes:

On Aug 13, 6:52 pm, j...@toerring.d e (Jens Thoms Toerring) wrote:

Daniel Molina Wegener <[e-mail] rote:

<snip>

The buffer isn't flushed?, apply fflush(3) over stdin.

fflush() can only be used for output streams, using it
for input is a Windows extension which doesn't work on
other systems.

It's not an extension, it's undefined behavior.

An implementation may define the behavior of a construct whose
behavior is not defined by the C standard. That's a valid way to
provide an extension.

Yes, I know. But C says it's UB, the impl says it's an extension.
This is comp.lang.c so I thought I should mention what C thinks of
that, because the poster did not mention UB.

But whether you call it an extension or UB, it's certainly
non-portable (and, in this particular case, unnecessary).

[Keith Thompson]

vi******@gmail. com writes:

On Aug 13, 7:58 pm, Keith Thompson <[e-mail] rote:

>vipps...@gmail .com writes:

On Aug 13, 6:52 pm, j...@toerring.d e (Jens Thoms Toerring) wrote:
Daniel Molina Wegener <[e-mail] rote:
<snip>

The buffer isn't flushed?, apply fflush(3) over stdin.

>fflush() can only be used for output streams, using it
for input is a Windows extension which doesn't work on
other systems.

It's not an extension, it's undefined behavior.

An implementation may define the behavior of a construct whose
behavior is not defined by the C standard. That's a valid way to
provide an extension.

Yes, I know. But C says it's UB, the impl says it's an extension.

And they're both right. But when the C standard says that something
is UB, it merely means that the C standard doesn't define the
behavior; other things (secondary standards like POSIX, or
implementations ) are free to define it.

You wrote:

It's not an extension, it's undefined behavior.

It *is* an extension, and it's undefined behavior only in that the
behavior isn't defined *by the C standard*.

This is comp.lang.c so I thought I should mention what C thinks of
that, because the poster did not mention UB.

>But whether you call it an extension or UB, it's certainly
non-portable (and, in this particular case, unnecessary).

--
Keith Thompson (The_Other_Keit h) ks***@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"