scanf() quesion?

[guoliang]

help:

#include<stdio.h>

int main(void)
{
int a;
char b;

printf("int=");
scanf("%d",&a);
fflush(stdin);
printf("char=");
scanf("%c",&b);

printf("a=%d, str=%c\n",a,b);
return 0;
}
input:1 and return;
output:char=a=1, b=

how can i assigment :a=1,b='x'?

[Richard Heathfield]

guoliang said:

help:

#include<stdio.h>

int main(void)
{
int a;
char b;

printf("int=");

If you want the prompt to appear before the program blocks for input,
ensure that this happens, either by completing the line or by flushing
the stream with fflush(stdout); this is because the standard output
stream is typically line-buffered.

scanf("%d",&a);

When you call scanf, you are asking for a resource (in this case,
information from the standard input stream). Whenever you ask for a
resource, the possibility exists that you don't get what you ask for,
and you should anticipate and deal with this possibility.

fflush(stdin);

The behaviour of fflush is defined only for streams open for output or
update. Since stdin is not such a stream, you invoke undefined
behaviour.

printf("char=");
scanf("%c",&b);

printf("a=%d, str=%c\n",a,b);
return 0;
}
input:1 and return;
output:char=a=1, b=

The only reason this isn't impossible is that the fflush(stdin) rendered
the behaviour of your program undefined.

how can i assigment :a=1,b='x'?

a = 1;
b = 'x';

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

[Martin Ambuhl]

guoliang wrote:

help:

#include<stdio.h>

int main(void)
{
int a;
char b;

printf("int=");
scanf("%d",&a);
fflush(stdin);
printf("char=");
scanf("%c",&b);

printf("a=%d, str=%c\n",a,b);
return 0;
}
input:1 and return;
output:char=a=1, b=

how can i assigment :a=1,b='x'?

While I don't think very highly of your approach to input, we'll work
with that. (By the way, 'assignment' is a noun, 'assign' is the verb,
and we usually use that term for the context of assignment statement.
But let that pass.)

#include<stdio.h>

int main(void)
{
int a;
char b = 0;

printf("int=");
fflush(stdout); /* fflush is defined only on _output_
streams, and you actually do need it
here, but not for the reason you
think. */
scanf("%d", &a);
while (getchar() != '\n') {
/* eat chars through end-of-line */ }
printf("char=");
fflush(stdout); /* and you need it here */
scanf("%c", &b);
printf("a=%d, b='%c'\n", a, b);
return 0;
}

[linarin]

After the first scanf of int values,you must skip one byte,may be \r
or space etc.
here is sample:

int a;
char b;
printf("Input:\n");
scanf("%d\r%c",&a,&b);
printf("%d,%c\n",a,b);
return 0;
here accept the following input:
1¡¢
5 + [enter key]
A + [enter key]

2¡¢
1 B+[enter key]
but it is bad idea to input data using scanf.
On 5ÔÂ11ÈÕ, ÏÂÎç3ʱ11·Ö, "guoliang" <[e-mail]:

help:

#include<stdio.h>

int main(void)
{
int a;
char b;

printf("int=");
scanf("%d",&a);
fflush(stdin);
printf("char=");
scanf("%c",&b);

printf("a=%d, str=%c\n",a,b);
return 0;}

input:1 and return;
output:char=a=1, b=

how can i assigment :a=1,b='x'?

[Army1987]

"Richard Heathfield" <rj*@see.sig.invalidha scritto nel messaggio
news:wN******************************@bt.com...

guoliang said:

>help:

#include<stdio.h>

int main(void)
{
int a;
char b;

printf("int=");

If you want the prompt to appear before the program blocks for input,
ensure that this happens, either by completing the line or by flushing
the stream with fflush(stdout); this is because the standard output
stream is typically line-buffered.

> scanf("%d",&a);

When you call scanf, you are asking for a resource (in this case,
information from the standard input stream). Whenever you ask for a
resource, the possibility exists that you don't get what you ask for,
and you should anticipate and deal with this possibility.

> fflush(stdin);

The behaviour of fflush is defined only for streams open for output or
update. Since stdin is not such a stream, you invoke undefined
behaviour.

> printf("char=");
scanf("%c",&b);

printf("a=%d, str=%c\n",a,b);
return 0;
}
input:1 and return;
output:char=a=1, b=

The only reason this isn't impossible is that the fflush(stdin) rendered
the behaviour of your program undefined.

Even without it, scanf("%d", &a); doesn't discard the newline,
which will be the first character read by scanf("%c", &b);

[Richard Heathfield]

Army1987 said:

>
"Richard Heathfield" <rj*@see.sig.invalidha scritto nel messaggio
news:wN******************************@bt.com...

>guoliang said:

<snip>

>>output:char=a=1, b=

The only reason this isn't impossible is that the fflush(stdin)
rendered the behaviour of your program undefined.

Even without it, scanf("%d", &a); doesn't discard the newline,
which will be the first character read by scanf("%c", &b);

Indeed. The OP would do better to eschew scanf completely, and use fgets
to capture input until such time as he is sufficiently skilled to
devise something better.

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

[Ajinkya]

On May 11, 5:27Â*am, linarin <[e-mail]:

After the first scanf of int values,you must skip one byte,may be \r
or space etc.
here is sample:

Â* Â* int a;
Â* Â* char b;
Â* Â* printf("Input:\n");
Â* Â* scanf("%d\r%c",&a,&b);
Â* Â* printf("%d,%c\n",a,b);
Â* Â* return 0;
here accept the following input:
1�
5 + [enter key]
A + [enter key]

2�
1 B+[enter key]

but it is bad idea to input data using scanf.

On 5月11日, 下�3时11分, "guoliang" <[e-mail]:

help:

#include<stdio.h>

int main(void)
{
Â*int a;
Â*char b;

Â*printf("int=");
Â*scanf("%d",&a);
Â*fflush(stdin);

i dont understand why fflush(stdin) is not working....its working for
me fine.
Can any one explain it.Is it compiler dependant?

Â*printf("char=");
Â*scanf("%c",&b);

Â*printf("a=%d, str=%c\n",a,b);
Â*return 0;}

input:1 and return;
output:char=a=1, b=

how can i assigment :a=1,b='x'?- Hide quoted text -

- Show quoted text -

[Chris Dollin]

Ajinkya wrote:

i dont understand why fflush(stdin) is not working....its working for
me fine.

You are unlucky, then.

Can any one explain it.Is it compiler dependant?

It is undefined by the C standard, so an implementation can
do /whatever it likes/, and it doesn't need to document its
decision.

Yours may happen to discard input. (How much input, and what happens
when stdin is connected to a file or a pipe or a network connection,
those are questions to wake you at night screaming.) Another
implementation might ignore it. Another may terminate your
program. Yet another may trash some random bytes of your code or
data. Yet another another may open a space-time rift and drop
you through it. All of these are OK according to the Standard,
since it leaves the behaviour completely open.

Watch out for weevils.

--
"Anything can happen in the next half-hour." /Stingray/

Hewlett-Packard Limited Cain Road, Bracknell, registered no:
registered office: Berks RG12 1HN 690597 England

[regis]

Richard Heathfield wrote:

guoliang said:

>printf("int=");

If you want the prompt to appear before the program blocks for input,
ensure that this happens, either by completing the line or by flushing
the stream with fflush(stdout); this is because the standard output
stream is typically line-buffered.

>scanf("%d",&a);

That's a thing I believed until recently, but now, I'm not anymore.
Unable to find a printf()+scanf() series that came to fail to display
the prompting message on time, I searched the Jan'99 Draft
and found this:

---------------------------
5.1.2.3 Environment (p. 18)

-- The input and output dynamics of interactive devices
shall take place as specified in 7.19.3. The intent of
these requirements is that unbuffered or line-buffered
output appear as soon as possible, to ensure that
prompting messages actually appear prior to a program
waiting for input.

7.19.3 File (p. 270)

[#3] When a stream is unbuffered, characters are intended to
appear from the source or at the destination as soon as
possible. Otherwise characters may be accumulated and
transmitted to or from the host environment as a block.
When a stream is fully buffered, characters are intended to
be transmitted to or from the host environment as a block
when a buffer is filled. When a stream is line buffered,
characters are intended to be transmitted to or from the
host environment as a block when a new-line character is
encountered. Furthermore, characters are intended to be
transmitted as a block to the host environment when a buffer
is filled, when input is requested on an unbuffered stream,

* or when input is requested on a line buffered stream that
requires the transmission of characters from the host
environment.*

Support for these characteristics is
implementation-defined, and may be affected via the setbuf
and setvbuf functions.
--------------------------

I'm not sure I understand all subtleties of the wording
above, so now, I don't know what to think...

--
regis

[CBFalconer]

Martin Ambuhl wrote:

>

.... snip ...

>
#include<stdio.h>

int main(void)
{
int a;
char b = 0;

printf("int=");
fflush(stdout); /* fflush is defined only on _output_
streams, and you actually do need it
here, but not for the reason you
think. */
scanf("%d", &a);

How do you know this worked?

while (getchar() != '\n') {
/* eat chars through end-of-line */ }

Infinite loop when the user supplies an EOF signal.

printf("char=");
fflush(stdout); /* and you need it here */
scanf("%c", &b);

How do you know this worked?

printf("a=%d, b='%c'\n", a, b);
return 0;
}

--
<http://www.cs.auckland.ac.nz/~pgut001/pubs/vista_cost.txt>
<http://www.securityfocus.com/columnists/423>
<http://www.aaxnet.com/editor/edit043.html>
<http://kadaitcha.cx/vista/dogsbreakfast/index.html>
cbfalconer at maineline dot net

--
Posted via a free Usenet account from http://www.teranews.com

[Keith Thompson]

regis <re***@dil.univ-mrs.frwrites:

Richard Heathfield wrote:

>guoliang said:

>>printf("int=");

If you want the prompt to appear before the program blocks for input,
ensure that this happens, either by completing the line or by flushing
the stream with fflush(stdout); this is because the standard output
stream is typically line-buffered.

>>scanf("%d",&a);

That's a thing I believed until recently, but now, I'm not anymore.
Unable to find a printf()+scanf() series that came to fail to display
the prompting message on time, I searched the Jan'99 Draft
and found this:

---------------------------
5.1.2.3 Environment (p. 18)

-- The input and output dynamics of interactive devices
shall take place as specified in 7.19.3. The intent of
these requirements is that unbuffered or line-buffered
output appear as soon as possible, to ensure that
prompting messages actually appear prior to a program
waiting for input.

7.19.3 File (p. 270)

[#3] When a stream is unbuffered, characters are intended to
appear from the source or at the destination as soon as
possible. Otherwise characters may be accumulated and
transmitted to or from the host environment as a block.
When a stream is fully buffered, characters are intended to
be transmitted to or from the host environment as a block
when a buffer is filled. When a stream is line buffered,
characters are intended to be transmitted to or from the
host environment as a block when a new-line character is
encountered. Furthermore, characters are intended to be
transmitted as a block to the host environment when a buffer
is filled, when input is requested on an unbuffered stream,

* or when input is requested on a line buffered stream that
requires the transmission of characters from the host
environment.*

Support for these characteristics is
implementation-defined, and may be affected via the setbuf
and setvbuf functions.

[...]

And see paragraph 7:

At program startup, three text streams are predefined and need not
be opened explicitly -- _standard input_ (for reading conventional
input), _standard output_ (for writing conventional output), and
_standard error_ (for writing diagnostic output). As initially
opened, the standard error stream is not fully buffered; the
standard input and standard output streams are fully buffered if
and only if the stream can be determined not to refer to an
interactive device.

If standard output refers to an interactive device, it can be either
unbuffered or line buffered. If it happens to be unbuffered, then
something like

printf("prompt: ");
fgets(line, N, stdin);

will work properly (i.e., the prompt will appear before the fgets()
call). If it happens to be line buffered, a call to fflush(stdout) is
required to get the same behavior. Such a call won't do any harm even
if stdout is unbuffered.

--
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."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[Richard Heathfield]

regis said:

Richard Heathfield wrote:

>guoliang said:

>>printf("int=");

If you want the prompt to appear before the program blocks for input,
ensure that this happens, either by completing the line or by
flushing the stream with fflush(stdout); this is because the standard
output stream is typically line-buffered.

>>scanf("%d",&a);

That's a thing I believed until recently, but now, I'm not anymore.

I don't have to believe it. I've seen it happen.

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

[CBFalconer]

linarin wrote:

>
After the first scanf of int values,you must skip one byte,may be \r
or space etc.
here is sample:

int a;
char b;
printf("Input:\n");
scanf("%d\r%c",&a,&b);
printf("%d,%c\n",a,b);
return 0;
here accept the following input:
1¡¢
5 + [enter key]
A + [enter key]

2¡¢
1 B+[enter key]

but it is bad idea to input data using scanf.

No, but it is an extremely bad idea to use it without checking the
return value.

Please do not top-post. Your answer belongs after (or intermixed
with) the quoted material to which you reply, after snipping all
irrelevant material. See the following links:

--
<http://www.catb.org/~esr/faqs/smart-questions.html>
<http://www.caliburn.nl/topposting.html>
<http://www.netmeister.org/news/learn2quote.html>
<http://cfaj.freeshell.org/google/ (taming google)
<http://members.fortunecity.com/nnqweb/ (newusers)

--
Posted via a free Usenet account from http://www.teranews.com

[regis]

Keith Thompson wrote:

regis <re***@dil.univ-mrs.frwrites:

>5.1.2.3 Environment (p. 18)

-- The input and output dynamics of interactive devices
shall take place as specified in 7.19.3. The intent of
these requirements is that unbuffered or line-buffered
output appear as soon as possible, to ensure that
prompting messages actually appear prior to a program
waiting for input.

7.19.3 File (p. 270)

[#3] When a stream is unbuffered, characters are intended to
appear from the source or at the destination as soon as
possible. Otherwise characters may be accumulated and
transmitted to or from the host environment as a block.
When a stream is fully buffered, characters are intended to
be transmitted to or from the host environment as a block
when a buffer is filled. When a stream is line buffered,
characters are intended to be transmitted to or from the
host environment as a block when a new-line character is
encountered. Furthermore, characters are intended to be
transmitted as a block to the host environment when a buffer
is filled, when input is requested on an unbuffered stream,
or when input is requested on a line buffered stream that
requires the transmission of characters from the host
environment.

And see paragraph 7:

At program startup, three text streams are predefined and need not
be opened explicitly -- _standard input_ (for reading conventional
input), _standard output_ (for writing conventional output), and
_standard error_ (for writing diagnostic output). As initially
opened, the standard error stream is not fully buffered; the
standard input and standard output streams are fully buffered if
and only if the stream can be determined not to refer to an
interactive device.

If standard output refers to an interactive device, it can be either
unbuffered or line buffered. If it happens to be unbuffered, then
something like

printf("prompt: ");
fgets(line, N, stdin);

will work properly (i.e., the prompt will appear before the fgets()
call). If it happens to be line buffered, a call to fflush(stdout) is
required to get the same behavior. Such a call won't do any harm even
if stdout is unbuffered.

The problem I have when I read 7.19.3[#3] is how
the sentence starting with "Furthermore..." should be
linked with the previous sentences, i.e., how the paragraph
would be indented if split into item-lists and sublists.

But, if I read you well, should I understand that
the sentence starting with "Furthermore..."
is a continuation of the case "When a stream is line buffered...",
and should not apply to all three cases mentioned above ?

Second, how to understand the expression "are indented to"?
Does it free an implementation from any obligation ?

Also, the expression "can be determined not to refer to":
is the implementation allowed to fail to determine it
when it really is ?

--
regis

[Keith Thompson]

regis <re**************@free.frwrites:

Keith Thompson wrote:

>regis <re***@dil.univ-mrs.frwrites:

>>5.1.2.3 Environment (p. 18)

-- The input and output dynamics of interactive devices
shall take place as specified in 7.19.3. The intent of
these requirements is that unbuffered or line-buffered
output appear as soon as possible, to ensure that
prompting messages actually appear prior to a program
waiting for input.

7.19.3 File (p. 270)

[#3] When a stream is unbuffered, characters are intended to
appear from the source or at the destination as soon as
possible. Otherwise characters may be accumulated and
transmitted to or from the host environment as a block.
When a stream is fully buffered, characters are intended to
be transmitted to or from the host environment as a block
when a buffer is filled. When a stream is line buffered,
characters are intended to be transmitted to or from the
host environment as a block when a new-line character is
encountered. Furthermore, characters are intended to be
transmitted as a block to the host environment when a buffer
is filled, when input is requested on an unbuffered stream,
or when input is requested on a line buffered stream that
requires the transmission of characters from the host
environment.

>And see paragraph 7:
At program startup, three text streams are predefined and need
not
be opened explicitly -- _standard input_ (for reading conventional
input), _standard output_ (for writing conventional output), and
_standard error_ (for writing diagnostic output). As initially
opened, the standard error stream is not fully buffered; the
standard input and standard output streams are fully buffered if
and only if the stream can be determined not to refer to an
interactive device.
If standard output refers to an interactive device, it can be either
unbuffered or line buffered. If it happens to be unbuffered, then
something like
printf("prompt: ");
fgets(line, N, stdin);
will work properly (i.e., the prompt will appear before the fgets()
call). If it happens to be line buffered, a call to fflush(stdout) is
required to get the same behavior. Such a call won't do any harm even
if stdout is unbuffered.

The problem I have when I read 7.19.3[#3] is how
the sentence starting with "Furthermore..." should be
linked with the previous sentences, i.e., how the paragraph
would be indented if split into item-lists and sublists.

But, if I read you well, should I understand that
the sentence starting with "Furthermore..."
is a continuation of the case "When a stream is line buffered...",
and should not apply to all three cases mentioned above ?

No, the "Furthermore..." sentence applies to all three. In fact, it
explicitly refers to all three cases:

Furthermore, characters are intended to be transmitted as a block
to the host environment

when a buffer is filled [fully buffered],

when input is requested on an unbuffered stream [unbuffered],

or when input is requested on a line buffered stream that
requires the transmission of characters from the host
environment [line buffered].

Second, how to understand the expression "are indented to"?
Does it free an implementation from any obligation ?

(Intended, not indented).

The sentence in question is:

When a stream is _unbuffered_, characters are intended to appear
from the source or at the destination as soon as possible.

The intent, I think, is that an implementation should satisfy this
requirement unless there's a good reason not to. The phrase "as soon
as possible" isn't precise enough to allow for a strict determination
of whether a given implementation conforms or not.

Also, the expression "can be determined not to refer to":
is the implementation allowed to fail to determine it
when it really is ?

Presumably, yes. Otherwise, it probably would have said

... are fully buffered if and only if the stream does not refer to
an interactive device.

rather than

... are fully buffered if and only if the stream can be determined
not to refer to an interactive device.

The standard (implicitly) recognizes that this determination might not
always be possible.

--
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."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[Chris Torek]

>Richard Heathfield wrote:

>>If you want [stdout output] to appear before the program
blocks for [stdin] input, ensure that this happens, either by
completing the line or by flushing the stream with fflush(stdout); ...

Best to use fflush(stdout).

In article <f2**********@news.univ-mrs.fr>
regis <re***@dil.univ-mrs.frwrote:

>That's a thing I believed until recently, but now, I'm not anymore.
Unable to find a printf()+scanf() series that came to fail to display
the prompting message on time ... [excerpt from Standard deleted]

If you have access to a Linux or Unix box, try:

./prog | tee save_output

and observe the fact that printf() output does not appear as
desired unless the fflush(stdout) calls are in place.

(This is one reason people use "script" instead of "tee". When
using "prog | tee", the implementation determines that stdout is
not connected to an "interactive device".)

(Programs that *do* use fflush(stdout) are well-behaved even when
running underneath pipes. Given the existence of "script", this
is not crucial, but it is convenient.)
--
In-Real-Life: Chris Torek, Wind River Systems
Salt Lake City, UT, USA (40°39.22'N, 111°50.29'W) [phone]
email: forget about it http://web.torek.net/torek/index.html
Reading email is like searching for food in the garbage, thanks to spammers.

[CBFalconer]

Ajinkya wrote:

>

.... snip ...

>
i dont understand why fflush(stdin) is not working....its working
for me fine. Can any one explain it. Is it compiler dependant?

It is undefined for input files. You may have a system that
extended its operation. That does not apply in general. See the C
standard. N1124.pdf is also good.

--
Some useful references about C:
<http://www.ungerhu.com/jxh/clc.welcome.txt>
<http://www.eskimo.com/~scs/C-faq/top.html (C-faq)
<http://benpfaff.org/writings/clc/off-topic.html>
<http://anubis.dkuug.dk/jtc1/sc22/wg14/www/docs/n869/(C99 std)
<http://www.dinkumware.com/refxc.html (C-library}
<http://gcc.gnu.org/onlinedocs/ (GNU docs)
<http://clc-wiki.net/wiki/C_community:comp.lang.c:Introduction>

--
Posted via a free Usenet account from http://www.teranews.com

[Richard Heathfield]

Chris Torek said:

If you have access to a Linux or Unix box, try:

./prog | tee save_output

and observe the fact that printf() output does not appear as
desired unless the fflush(stdout) calls are in place.

Ouch! A lesson learned.

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

[Army1987]

"regis" <re***@dil.univ-mrs.frha scritto nel messaggio
news:f2**********@news.univ-mrs.fr...

Richard Heathfield wrote:

>guoliang said:

>>printf("int=");

If you want the prompt to appear before the program blocks for input,
ensure that this happens, either by completing the line or by flushing
the stream with fflush(stdout); this is because the standard output
stream is typically line-buffered.

>>scanf("%d",&a);

That's a thing I believed until recently, but now, I'm not anymore.
Unable to find a printf()+scanf() series that came to fail to display
the prompting message on time, I searched the Jan'99 Draft
and found this:

I have written a program with putchar()s a character from a string
determined from its first line argument (the first character if
there's no first line argument), and then calls itself (via system()) with
an argument which causes it to write the next character.
<semi-ot reason="the behaviour of system() itself is
implementation-defined">
If I don't fflush(stdout) after putchar, the string is displayed
backwards. Figuring out why is left as an exercise.</semi-ot>

[Army1987]

"Martin Ambuhl" <ma*****@earthlink.netha scritto nel messaggio
news:5a*************@mid.individual.net...

scanf("%d", &a);
while (getchar() != '\n') {
/* eat chars through end-of-line */ }

what if it hits EOF? (BTW, I think you can use scanf("%d%*[^\n]%*c", &a);
The asterisks mean "discard". %*[^\n] means "discard all consecutive
next characters which aren't \n" and %*c means "discard next character".)

[zwgao83]

On May 11, 3:11 pm, "guoliang" <[e-mail]:

help:

#include<stdio.h>

int main(void)
{
int a;
char b;

printf("int=");
scanf("%d",&a);
fflush(stdin);
printf("char=");
scanf("%c",&b);

printf("a=%d, str=%c\n",a,b);
return 0;}

input:1 and return;
output:char=a=1, b=

how can i assigment :a=1,b='x'?

it works fine for me .my environment is winxp+mingw gcc 3.4.2.
i find the fflush refrence from msdn:

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.

if you comment out fflush(stdin); ,the result is the same to yours:
char=a=1,b=

[Army1987]

<zw*****@gmail.comha scritto nel messaggio
news:11**********************@q75g2000hsh.googlegr oups.com...

On May 11, 3:11 pm, "guoliang" <[e-mail]:

>help:

#include<stdio.h>

int main(void)
{
int a;
char b;

printf("int=");
scanf("%d",&a);
fflush(stdin);
printf("char=");
scanf("%c",&b);

printf("a=%d, str=%c\n",a,b);
return 0;}

input:1 and return;
output:char=a=1, b=

how can i assigment :a=1,b='x'?

it works fine for me .my environment is winxp+mingw gcc 3.4.2.
i find the fflush refrence from msdn:

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.

"Undefined behaviour" can be this. You're lucky that your
implementation does document it, it doesn't have to (unlike the
case of implementation defined behaviour). But on comp.lang.c not
everybody has the same compiler as yours, so please don't use
things triggering such a behaviour, or post to some other group
where you can expect everybody to be familiar with your
implementation. (If you *really* have to insert some
implementation-specified feature, *and* the question isn't about
it, but about some part of the program with is standard C, try
posting anyway and explicitly say what that feature does. But some
might regard that as off-topic.)

[regis]

Chris Torek wrote:

>Richard Heathfield wrote:

>>If you want [stdout output] to appear before the program
blocks for [stdin] input, ensure that this happens, either by
completing the line or by flushing the stream with fflush(stdout); ...

Best to use fflush(stdout).

In article <f2**********@news.univ-mrs.fr>
regis <re***@dil.univ-mrs.frwrote:

>That's a thing I believed until recently, but now, I'm not anymore.
Unable to find a printf()+scanf() series that came to fail to display
the prompting message on time ... [excerpt from Standard deleted]

If you have access to a Linux or Unix box, try:

./prog | tee save_output

and observe the fact that printf() output does not appear as
desired unless the fflush(stdout) calls are in place.

indeed. I did and observed.

Thank you, Chris and Keith, for your answers.

--
regis

[Bart van Ingen Schenau]

zw*****@gmail.com wrote:

>
it works fine for me .my environment is winxp+mingw gcc 3.4.2.
i find the fflush refrence from msdn:

Please not that msdn describes the behaviour of one particular compiler
and its library (the Microsoft compiler and library).
Therefor, it is not a definitive source of information on how all C
compilers should behave.

With fflush() for example, Microsoft has chosen to provide (sensible?)
defined behaviour for flushing input streams, which is explicitly left
undefined by the C language definition (i.e. the C standard).
This only means that when you use the Microsoft fflush() implementation,
you know what will happen if you flush an input stream. For other
implementations this is generally not true.

Bart v Ingen Schenau
--
a.c.l.l.c-c++ FAQ: http://www.comeaucomputing.com/learn/faq
c.l.c FAQ: http://www.eskimo.com/~scs/C-faq/top.html
c.l.c++ FAQ: http://www.parashift.com/c++-faq-lite/

[guru.jois]

On May 11, 12:47 pm, Richard Heathfield <[e-mail]:

guoliang said:

help:

#include<stdio.h>

int main(void)
{
int a;
char b;

printf("int=");

If you want the prompt to appear before the program blocks for input,
ensure that this happens, either by completing the line or by flushing
the stream with fflush(stdout); this is because the standard output
stream is typically line-buffered.

scanf("%d",&a);

When you call scanf, you are asking for a resource (in this case,
information from the standard input stream). Whenever you ask for a
resource, the possibility exists that you don't get what you ask for,
and you should anticipate and deal with this possibility.

fflush(stdin);

The behaviour of fflush is defined only for streams open for output or
update. Since stdin is not such a stream, you invoke undefined
behaviour.

printf("char=");
scanf("%c",&b);

printf("a=%d, str=%c\n",a,b);
return 0;
}
input:1 and return;
output:char=a=1, b=

The only reason this isn't impossible is that the fflush(stdin) rendered
the behaviour of your program undefined.

how can i assigment :a=1,b='x'?

a = 1;
b = 'x';

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

or do this

scanf (" %c", &c); // space before %c..

[Richard Heathfield]

gu*******@gmail.com said:

On May 11, 12:47 pm, Richard Heathfield <[e-mail]:

>guoliang said:

<snip>

scanf("%d",&a);

When you call scanf, you are asking for a resource (in this case,
information from the standard input stream). Whenever you ask for a
resource, the possibility exists that you don't get what you ask for,
and you should anticipate and deal with this possibility.

<snip>

or do this

scanf (" %c", &c); // space before %c..

See above.

I sometimes think the ability to read is becoming unfashionable.

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

[CBFalconer]

Richard Heathfield wrote:

gu*******@gmail.com said:

>Richard Heathfield <[e-mail]:

>>guoliang said:

<snip>

>>> scanf("%d",&a);

When you call scanf, you are asking for a resource (in this case,
information from the standard input stream). Whenever you ask for
a resource, the possibility exists that you don't get what you
ask for, and you should anticipate and deal with this possibility.

<snip>

>or do this

scanf (" %c", &c); // space before %c..

See above.

I sometimes think the ability to read is becoming unfashionable.

To clear up the probable confusion, NEVER use scanf without
checking its returned success indication. Read up on what that is.

--
<http://www.cs.auckland.ac.nz/~pgut001/pubs/vista_cost.txt>
<http://www.securityfocus.com/columnists/423>
<http://www.aaxnet.com/editor/edit043.html>
<http://kadaitcha.cx/vista/dogsbreakfast/index.html>
cbfalconer at maineline dot net

--
Posted via a free Usenet account from http://www.teranews.com

[David Thompson]

On Sat, 12 May 2007 12:02:43 +0200, "Army1987" <pl********@for.it>
wrote:

>
"Martin Ambuhl" <ma*****@earthlink.netha scritto nel messaggio
news:5a*************@mid.individual.net...

scanf("%d", &a);
while (getchar() != '\n') {
/* eat chars through end-of-line */ }

what if it hits EOF? (BTW, I think you can use scanf("%d%*[^\n]%*c", &a);

Yes, you do need to check for returned EOF. As well as checking the
return value from scanf. Always.

But the scanf alternative you suggest, as others often have (for
fairly modest values of often), doesn't quite work.

The asterisks mean "discard". %*[^\n] means "discard all consecutive
next characters which aren't \n" and %*c means "discard next character".)

That much is correct. But *scanf also does one directive at a time,
and when one directive fails stops and returns without doing any more.

Thus 123xyz\n will read the number, skip the xyz, and skip the
newline. But 123\n will read the number, fail to match any nonnewline
character, and LEAVE the newline pending, which may screw up the next
input depending on what that is.

If you are careful, you can make a combination of scanf and (one)
getchar, or two scanf's, work. But it is arguably ugly, and definitely
not as clear as the straightforward loop.

- formerly david.thompson1 || achar(64) || worldnet.att.net