Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C Programming > confused about behaviour of scanf

Reply
Thread Tools

confused about behaviour of scanf

 
 
pemo
Guest
Posts: n/a
 
      12-21-2005

"Anand" <(E-Mail Removed)> wrote in message
news:059qf.1$(E-Mail Removed)...
> [Corrected quoting]
> --- Quoting from others ---------
> <Quote>
> It is proper Usenet etiquette to include the relevant portions of the text
> you are replying to. To do this using Google groups, please follow the
> instructions below, penned by Keith Thompson:
>
> 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.
> </Quote>
>
> alok wrote:
> > Michael Mair wrote:
> >> See the comp.lang.c FAQ 12.17, 12.18a, 12.19, 12.20 and search
> >> the comp.lang.c archives.
> >>
> >> Note: fflush(stdin) is _not_ the solution. getchar() can be.
> >>
> >> Cheers
> >> Michael

> >
>> i m running this program in MS VC++ & Solaris gcc after using
>> fflush(stdin) , it is working fine .
>> so y fflush(stdin) is _not_ the solution ?
>>

>
> Because the standard says so
> C99 7.19.5.2
> "
> Ifstream points to an output stream or an update stream in which the most
> recent operation was not input, the fflush function causes any unwritten
> data for that stream to be delivered to the host environment to be written
> to the file; otherwise, the behavior is undefined.
> "
>
> Since it is undefined anything can happen. It might be working for you now
> and it might be the feature of the compiler not the language.


It would be sooo simple if there were a way to test stdin for
eof/empty-buffer


 
Reply With Quote
 
 
 
 
Barry Schwarz
Guest
Posts: n/a
 
      12-21-2005
On 21 Dec 2005 00:29:21 -0800, "alok" <(E-Mail Removed)> wrote:

>i m running this program in MS VC++ & after using fflush(stdin) , it
>is working fine .
>so y fflush(stdin) is _not_ the solution ?


it s nt the sltn because fflush is defined only for output streams .
Calling fflush for an input stream invokes undefined behavior. One of
the unluckiest manifestations of undefined behavior is the appearance
of working as expected and thereby misleading you to think it is
correct. This usually lasts until you have to demo the product to
your boss or a client.

The discussion of MS VC++ features/anomalies/ is properly done in one
of the microsoft.*.* groups. This group is about standard C


<<Remove the del for email>>
 
Reply With Quote
 
 
 
 
Ed Prochak
Guest
Posts: n/a
 
      12-21-2005

pemo wrote:
> "Anand" <(E-Mail Removed)> wrote in message
> news:059qf.1$(E-Mail Removed)...

[]
> >
> > alok wrote:

[]
> >> i m running this program in MS VC++ & Solaris gcc after using
> >> fflush(stdin) , it is working fine .
> >> so y fflush(stdin) is _not_ the solution ?
> >>

> >
> > Because the standard says so
> > C99 7.19.5.2

[]
>
> It would be sooo simple if there were a way to test stdin for
> eof/empty-buffer


There is
while ( !fgets( buffer, size, STDIN) ) { ...
or
while ( !(nextch=getchar()) ) { ...

Do people not read the documentation of the functions they use?


ed

 
Reply With Quote
 
Flash Gordon
Guest
Posts: n/a
 
      12-21-2005
Ed Prochak wrote:
> pemo wrote:
>> "Anand" <(E-Mail Removed)> wrote in message
>> news:059qf.1$(E-Mail Removed)...

> []
>>> alok wrote:

> []
>>>> i m running this program in MS VC++ & Solaris gcc after using
>>>> fflush(stdin) , it is working fine .
>>>> so y fflush(stdin) is _not_ the solution ?
>>>>
>>> Because the standard says so
>>> C99 7.19.5.2

> []
>> It would be sooo simple if there were a way to test stdin for
>> eof/empty-buffer

>
> There is
> while ( !fgets( buffer, size, STDIN) ) { ...
> or
> while ( !(nextch=getchar()) ) { ...


Neither of your suggestions tests for an empty buffer for an empty
buffer since the functions you are calling will just sit there until
either there is something in the buffer or they detect an end-of-file or
error condition. Your use of getchar is completely wrong, since it
returns EOF, not 0, or either end-of-file or error. You don't attempt to
distinguish between an error and end-of-file (which can be done).

> Do people not read the documentation of the functions they use?


Obviously not.

Standard C provides no mechanism for detecting whether there is anything
in the buffer ready to be read, which I consider to be a shame. It
would, IMHO, be useful if standard C had a bufempty function with four
return values, empty, non-empty, full and unknown, but it does not exist
in standard C.
--
Flash Gordon
Living in interesting times.
Although my email address says spam, it is real and I read it.
 
Reply With Quote
 
Michael Mair
Guest
Posts: n/a
 
      12-21-2005
Ed Prochak wrote:
> pemo wrote:
>
>>"Anand" <(E-Mail Removed)> wrote in message
>>news:059qf.1$(E-Mail Removed)...

>
> []
>
>>>alok wrote:

>
> []
>
>>>>i m running this program in MS VC++ & Solaris gcc after using
>>>>fflush(stdin) , it is working fine .
>>>>so y fflush(stdin) is _not_ the solution ?
>>>>
>>>
>>>Because the standard says so
>>>C99 7.19.5.2

>
> []
>
>>It would be sooo simple if there were a way to test stdin for
>>eof/empty-buffer

>
>
> There is
> while ( !fgets( buffer, size, STDIN) ) { ...

ITYM: stdin
> or
> while ( !(nextch=getchar()) ) { ...

ITYM: EOF != (nextch = getchar())

> Do people not read the documentation of the functions they use?


"Real men don't need to read the manual" or, in this case, the
documentation... ;-(

Cheers
Michael
--
E-Mail: Mine is an /at/ gmx /dot/ de address.
 
Reply With Quote
 
Michael Mair
Guest
Posts: n/a
 
      12-21-2005
alok wrote:
> i m running this program in MS VC++ & Solaris gcc after using
> fflush(stdin) , it is working fine .
> so y fflush(stdin) is _not_ the solution ?


Apart from the missing context: Please try to write something
resembling written English, especially write whole words.

As others have told you: fflush(stdin) has no defined behaviour
from the standard C point of view.

Slighty off-topic example:
Consider the many breaking changes from MSVC++6 to
MSVC++2003 and 2005 which nearly all concern the change from
not standard-conforming to standard-conforming behaviour (especially
for the C++ part). If the people relying on non-standard stuff had
written the things as standard-conforming as possible, they would
not have had to rewrite huge parts of their code.

So, as there exists a perfectly portable and viable solution to
your problem, it is reasonable to use it instead of a solution
which may not work after a change of platform, operating system,
compiler or even compiler version.

Cheers
Michael
--
E-Mail: Mine is an /at/ gmx /dot/ de address.
 
Reply With Quote
 
Keith Thompson
Guest
Posts: n/a
 
      12-21-2005
"Ed Prochak" <(E-Mail Removed)> writes:
> pemo wrote:
>> "Anand" <(E-Mail Removed)> wrote in message
>> news:059qf.1$(E-Mail Removed)...

> []
>> >
>> > alok wrote:

> []
>> >> i m running this program in MS VC++ & Solaris gcc after using
>> >> fflush(stdin) , it is working fine .
>> >> so y fflush(stdin) is _not_ the solution ?
>> >>
>> >
>> > Because the standard says so
>> > C99 7.19.5.2

> []
>>
>> It would be sooo simple if there were a way to test stdin for
>> eof/empty-buffer

>
> There is
> while ( !fgets( buffer, size, STDIN) ) { ...
> or
> while ( !(nextch=getchar()) ) { ...


Which, as others have pointed out, doesn't check for an empty buffer.

A feature I've seen elsewhere is the ability to flush the input buffer
before reading input after a prompt. For example, given:

printf("Enter a string: ");
fflush(stdout); /* make sure the prompt appears */
flush_input_buffer(stdin);
fgets(s, LEN, stdin);

any characters typed by the user before the prompt appears would be
discarded. Ordinarily they'd be saved in the typeahead buffer; if the
user guessed wrong about wnat the next prompt was going to be, bad
things could happen.

C provides no standard way to do this, mostly because it doesn't
assume stdin is an interactive device such as a keyboard. <OT>I've
used systems that had this feature; I think it was FLUSH(INPUT); in
UCSD PAscal.</OT>

--
Keith Thompson (The_Other_Keith) http://www.velocityreviews.com/forums/(E-Mail Removed) <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.
 
Reply With Quote
 
John Bode
Guest
Posts: n/a
 
      12-21-2005
Lalatendu Das wrote:
> Dear friends,
> I am getting a problem in the code while interacting with a nested
> Do-while loop
> It is skipping a scanf () function which it should not. I have written
> the whole code below. Please help me in finding why such thing is
> happening and what the remedy to it is. Kindly bear with my English.
>
>


The problem is that you have a stray newline character stuck in the
input stream after the first scanf(). For example, suppose you type
1234 at the prompt and hit Return. The input stream then contains the
characters '1', '2', '3', '4', and '\n'. The "%d" conversion specifier
tells scanf() to skip any leading whitespace, and to read and convert
all numeric (decimal) characters up to the first non-numeric character.
So the first scanf() reads the '1', '2', '3', and '4' characters from
the input stream and stops. This leaves the '\n' character still in
the input stream. The "%c" conversion specifier tells scanf() to read
and assign the next character. So the second scanf() call sees the
'\n' in the input stream and assigns it to ch, but to you it looks like
the second scanf() is being skipped.

There are several ways around this. The simplest option is to change
the second scanf() to use the "%s" conversion specifier and read a
string instead of a single character. The "%s" conversion specfier
will skip any leading whitespace, so stray newlines won't cause
problems (however, other stray characters might; that's a different
thread, though). It means changing ch from a single char to an array,
but that's no big deal:

char ch[2];
....
printf("Do you want to refill the array again y/n: ");
fflush(stdout);
scanf("%1s", ch);
if (ch[0] == 'y')
{
...
}

It's not a robust solution, but it'll get you past this particular
issue.

> int
> main ()
> {
> int num1[4] , i = 0 ;
> char ch ;
>
> do
> {
> do
> {
> printf ("Enter the number in the array \n");
> scanf("%d",&num[i] );
> i++;
> } while (i<=3);
>
> printf("Do u want to refill the array again y/n
> \n");
> scanf ("%c", &ch); /* This line is skipped, it
> is not
> prompting to
> give input
> from keyboard
> */
>
> } while (ch = = 'y') ; /* In gdb 'ch' is
> showing the value same as
> it has at the time of declaration i.e.
> some garbage */
>
> return 0;
> }
>
> I know this is very silly question for many of u but still I am in
> ambiguity to resolve it . So please send me all possible way of
> resolving it. and why such problem occurring. The environment in which
> I have done it is gcc-3.2.2, red hat Linux -9 , debugged using gdb .


 
Reply With Quote
 
chump1708@yahoo.com
Guest
Posts: n/a
 
      12-21-2005

Lalatendu Das wrote:
> Dear friends,
> I am getting a problem in the code while interacting with a nested
> Do-while loop
> It is skipping a scanf () function which it should not. I have written
> the whole code below. Please help me in finding why such thing is
> happening and what the remedy to it is. Kindly bear with my English.
>
>
> int
> main ()
> {
> int num1[4] , i = 0 ;
> char ch ;
>
> do
> {
> do
> {
> printf ("Enter the number in the array \n");
> scanf("%d",&num[i] );
> i++;
> } while (i<=3);
>
> printf("Do u want to refill the array again y/n
> \n");
> scanf ("%c", &ch); /* This line is skipped, it
> is not
> prompting to
> give input
> from keyboard
> */
>
> } while (ch = = 'y') ; /* In gdb 'ch' is
> showing the value same as
> it has at the time of declaration i.e.
> some garbage */
>
> return 0;
> }
>
> I know this is very silly question for many of u but still I am in
> ambiguity to resolve it . So please send me all possible way of
> resolving it. and why such problem occurring. The environment in which
> I have done it is gcc-3.2.2, red hat Linux -9 , debugged using gdb .


what if we use
scanf ("% c", &ch); //using a space between % and c
Does this help to eliminate the new line charater in the buffer????

 
Reply With Quote
 
Lalatendu Das
Guest
Posts: n/a
 
      12-22-2005
Alok
whatever u have suggested is the same which came to my mind
also . but it fails when tried . it might work in vc++ or any other
but in redhat linux 9/ gcc 3.2.2 (as i have mentioned before) it fails
to work . so i need a solution which work for everything.

And have also asked one of my teacher about this then , he told me to
scan a pointer using fgets(). just before scanf it will eradicate the
problem .
char *test ;
test = (char *) malloc(11);
fgets( test , 11 , stdin);
though this works but this is not a rsonable and genuine way to
eradiacate the problem as where i will implement such things it will
going to change the design .

 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
scanf(), ungetc() behaviour. Argento C Programming 62 10-06-2006 11:04 PM
difference between scanf("%i") and scanf("%d") ??? perhaps bug inVS2005? =?ISO-8859-1?Q?Martin_J=F8rgensen?= C Programming 18 05-02-2006 10:53 AM
scanf (yes/no) - doesn't work + deprecation errors scanf, fopen etc. =?ISO-8859-1?Q?Martin_J=F8rgensen?= C Programming 185 04-03-2006 02:49 PM
Scanf Behaviour sajjanharudit@gmail.com C Programming 7 12-30-2005 07:20 PM
Correct behaviour of scanf and sscanf Rob Thorpe C Programming 6 03-15-2005 04:25 PM



Advertisments