how to check the scanf function if it will read more than one number

[moosdau]

my code:
do
{
printf("please input the dividend and the divisor.\n");
if(!scanf("%d%d ",&dend,&do r))
{
temp1=1;
fflush(stdin);
}
else
temp1=0;
}while(temp1==1 );

it seems that it only depend on the first number it read.
if I input " a 32 ", it could know there is a error,
but if I input " 32 a ",
it accept that.

thanks in advance.

[Moosdau]

Peter Nilsson wrote:

Your implementation probably defines a behaviour fflush on
input streams. It would do so as an extension. That extension
is not topical in comp.lang.c.

it do be that.
I think I've already known the answer.
the below is I copied 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.

Example
// crt_fflush.c
#include <stdio.h>
#include <conio.h>

int main( void )
{
int integer;
char string[81];

/* Read each word as a string. */
printf( "Enter a sentence of four words with scanf: " );
for( integer = 0; integer < 4; integer++ )
{
scanf( "%s", string );
// Security caution!
// Beware allowing user to enter data directly into a buffer
// without checking for buffer overrun possiblity.
printf( "%s\n", string );
}

/* You must flush the input buffer before using gets. */
fflush( stdin ); // fflush on input stream is an extension to the
C standard
printf( "Enter the same sentence with gets: " );
gets( string );
printf( "%s\n", string );
}
Input
This is a test
This is a test
Sample Output
Enter a sentence of four words with scanf: This is a test
This
is
a
test
Enter the same sentence with gets: This is a test
This is a test
then I know,I shouldn't use fflush(stdin) except in VC.
but in VC, it is safe.

thanks to all again !

[Keith Thompson]

"Moosdau" <mo*****@gmail. com> writes:

Peter Nilsson wrote:

Your implementation probably defines a behaviour fflush on
input streams. It would do so as an extension. That extension
is not topical in comp.lang.c.
it do be that.
I think I've already known the answer.
the below is I copied 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.

Example
// crt_fflush.c
#include <stdio.h>
#include <conio.h>

int main( void )
{

[snip] int integer;
char string[81];

/* Read each word as a string. */
printf( "Enter a sentence of four words with scanf: " );
for( integer = 0; integer < 4; integer++ )
{
scanf( "%s", string );
// Security caution!
// Beware allowing user to enter data directly into a buffer
// without checking for buffer overrun possiblity.
printf( "%s\n", string );
}
So MSDN shows an example of a possible buffer overflow and provides a
comment that doesn't give you a clue how to avoid it.
/* You must flush the input buffer before using gets. */
fflush( stdin ); // fflush on input stream is an extension to the
C standard
printf( "Enter the same sentence with gets: " );
gets( string );
printf( "%s\n", string );
}
And the example uses gets() without even warning that it's unsafe.
For nearly all practical purposes, gets() cannot be used safely.

[snip]
then I know,I shouldn't use fflush(stdin) except in VC.
but in VC, it is safe.

Here's a better idea: don't use fflush(stdin) at all. Second best:
don't use fflush(stdin) unless you're certain your code will never be
ported to an implementation that doesn't support it.

--
Keith Thompson (The_Other_Keit h) 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.

[Chuck F.]

Moosdau wrote:

Peter Nilsson wrote:

Your implementation probably defines a behaviour fflush on
input streams. It would do so as an extension. That extension
is not topical in comp.lang.c.

it do be that. I think I've already known the answer. the below
is I copied 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.

Which is typical of Microsoft ignoring standards. They encourage
people to write non-standard code, which is then tied to their own
systems, and thus increases their income.

For general systems where what, if anything, functions as an input
mechanism is not defined, the C language has no control. There is
no way it can possibly anticipate the arrival of input. Thus input
routines, when called, have to await actual input before returning.
There may not be any input buffer, and if there is there is no
defined way of interrogating it for non-emptyness. Thus the
language cannot insist on fflush functioning on input streams, and
any attempt to so do makes the program non-portable.

--
"If you want to post a followup via groups.google.c om, 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
More details at: <http://cfaj.freeshell. org/google/>

[Richard Heathfield]

Keith Thompson said:

Richard Heathfield <in*****@invali d.invalid> writes:

Emmanuel Delahaye said:

Note that the 'return;' is useless.

Only to the compiler.

Implying that it's useful to the reader? This was a "return;" at the
very end of a void function; how is that useful at all?

It's a tiny, tiny advantage, but an advantage nonetheless, at least to me.

My functions generally have one entry point and one exit point. The exit
point is the return statement. So I'm accustomed to writing one in each
function, generally as the /last/ line typed in the first cut of the
function. (The closing brace is typed immediately after the opening brace,
to save me from encountering pairing-up nonsenses later.)

So, when I see a function with no return statement, I find myself thinking
"is this function finished yet?"

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

[Richard Heathfield]

Moosdau said:

Richard Heathfield wrote:

For the same reason that pressing the handle on your toilet will not get
rid of the water waiting in your sink's tap (or faucet, if you're on that
side of the pond). Flushing is something we do to output, not to input.
thanks.
but what I want to know is the "actual" reason,
not a "logical" one.

I gave you both in my previous reply; as well as the text you quote above, I
also wrote: "Because fflush's behaviour is only defined for streams open
for output or update." That is the actual reason.
if p is a NULL pointer, p->num will cause the error.
The C Standard assures us the code is wrong to dereference a null pointer,
but it does not specify that there will be "an error". It only says the
behaviour is undefined.
so ,the fflush function works very well on my computer now,
That's nice.
If it cause a potential danger,
If you use it in a way it was never intended to be used, that's a potential
danger.
I want to know what is it, and what is the condition.
if possible, an example is the best. :)

Okay, here's an example. Let's say you choose to use fflush(stdin) because
Microsoft say it's okay, and then in five years time Microsoft goes bust
and everyone starts using Macs instead, and you port your code to a Mac and
suddenly it stops working, and the reason it stops working is that you
thought "MSDN" was an acceptable substitute for "The ISO C Standard" and
wrote your code on that basis. Well, if you want to create unnecessary
portability headaches for yourself, that's your lookout.

The irony is that this is such a pointless discussion, since you simply
don't /need/ to "flush" input. Well, I don't, anyway, and I do a /lot/ of
text processing in C.

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

[Moosdau]

Richard Heathfield wrote:

Okay, here's an example. Let's say you choose to use fflush(stdin) because
Microsoft say it's okay, and then in five years time Microsoft goes bust
and everyone starts using Macs instead, and you port your code to a Mac and
suddenly it stops working, and the reason it stops working is that you
thought "MSDN" was an acceptable substitute for "The ISO C Standard" and
wrote your code on that basis. Well, if you want to create unnecessary
portability headaches for yourself, that's your lookout.
haha !
The irony is that this is such a pointless discussion, since you simply
don't /need/ to "flush" input. Well, I don't, anyway, and I do a /lot/ of
text processing in C.
but ,seriously , if the ISO can provide a compiler that obey it's
standard absolutely,
how cool will that be!
--
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)

[Dik T. Winter]

In article <11************ **********@g43g 2000cwa.googleg roups.com> "Moosdau" <mo*****@gmail. com> writes:

Richard Heathfield wrote:

For the same reason that pressing the handle on your toilet will not
get rid of the water waiting in your sink's tap (or faucet, if you're
on that side of the pond). Flushing is something we do to output, not
to input.

thanks.
but what I want to know is the "actual" reason,
not a "logical" one.

It is not well-defined in general what flushing the input stream means.
Especially when you are connected through a network. Does it mean
discarding all input that has arrived at the computer where the
program is running? Does it mean discarding also all input that is
still somewhere on the way on the network? And if so how does the
system know what was already on the way when fflush was called and
what was not yet on the way?
--
dik t. winter, cwi, kruislaan 413, 1098 sj amsterdam, nederland, [phone]
home: bovenover 215, 1025 jn amsterdam, nederland; http://www.cwi.nl/~dik/

[pemo]

"Keith Thompson" <ks***@mib.or g> wrote in message
news:ln******** ****@nuthaus.mi b.org...

"pemo" <us***********@ gmail.com> writes:

"Keith Thompson" <ks***@mib.or g> wrote in message
news:ln******** ****@nuthaus.mi b.org...

"pemo" <us***********@ gmail.com> writes: [...] Would this be acceptable for stdin?

void flushstdin(void )
{
while(getchar() != '\n')
;

return;
}

What if getchar() returns EOF before returning '\n'?

Surely, if there's a \n in the buffer, getchar won't return EOF?

If there's not a \n in the buffer, I can see that testing for EOF might
be a
good idea.

So perhaps you should do something like this:

void flushstdin(void )
{
if (theres_a_newli ne_in_the_buffe r()) {
while(getchar() != '\n')
;
}
else {
int c;
while(c = getchar(), c != '\n' && c != EOF)
;
}
}

Implementing the theres_a_newlin e_in_the_buffer () function in portable
C is left as an exercise. If you can't think of a way to do it,
perhaps you should just test for EOF.

To answer my own question from upthread, if you reach EOF on stdin
before seeing a '\n' character, your flushstdin() function becomes an
infinite loop; getchar() will repeatedly return EOF, and the condition
will never allow the loop to terminate.

Ok, point taken.

[pemo]

"Richard Heathfield" <in*****@invali d.invalid> wrote in message
news:dp******** **@nwrdmz02.dmz .ncs.ea.ibs-infra.bt.com...

Keith Thompson said:

Richard Heathfield <in*****@invali d.invalid> writes:

Emmanuel Delahaye said:

Note that the 'return;' is useless.

Only to the compiler.

Implying that it's useful to the reader? This was a "return;" at the
very end of a void function; how is that useful at all?

It's a tiny, tiny advantage, but an advantage nonetheless, at least to me.

My functions generally have one entry point and one exit point. The exit
point is the return statement. So I'm accustomed to writing one in each
function, generally as the /last/ line typed in the first cut of the
function. (The closing brace is typed immediately after the opening brace,
to save me from encountering pairing-up nonsenses later.)

So, when I see a function with no return statement, I find myself thinking
"is this function finished yet?"

It's the same with me - plus - [and it's a similar point] I also have a
personal problem with being as explicit as possible - in that I always try
to be!

[pemo]

"Emmanuel Delahaye" <em***@YOURBRAn oos.fr> wrote in message
news:43******** **************@ nan-newsreader-06.noos.net...

pemo a écrit :

Not in good tutorials.

I didn't think that there were any????

http://publications.gbdirect.co.uk/c_book/

Any other testimonials for this?