scanf() quesion?

[Army1987]

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]

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).

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.

 

[Bart van Ingen Schenau]

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

 

[guru.jois]

guoliang said:



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.


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.


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.



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


a = 1;
b = 'x';

or do this

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

 

[Richard Heathfield]

(e-mail address removed) said:

or do this

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

See above.

I sometimes think the ability to read is becoming unfashionable.

 

[David Thompson]

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