Velocity Reviews - Computer Hardware Reviews

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

Reply
Thread Tools

confused about behaviour of scanf

 
 
Lalatendu Das
Guest
Posts: n/a
 
      12-22-2005
Thanks i found many good suggestions from the group and many
clarifications which i assumed wrong .

thanks to the group members

 
Reply With Quote
 
 
 
 
Ed Prochak
Guest
Posts: n/a
 
      12-23-2005

Flash Gordon wrote:
> 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.


Empty buffer is what you might have After the return. This is not
realtime I/O or raw terminal I/O. If the OP wants that they need to
look elsewhere.

> Your use of getchar is completely wrong, since it
> returns EOF, not 0, or either end-of-file or error.


You are right. I did it quickly and should have double checked (I did
put in EOF originally but then for some reaon I thought it wasn simpler
this way. Too much thinking). Thanks for the catch.

> You don't attempt to
> distinguish between an error and end-of-file (which can be done).


He did not ask about error checking, that comes outside the loop.

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

>
> Obviously not.


I got sloppy on getchar(). my apologies to all.
>
> 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.


in the getchar() case there is no buffer.
in the fgets() case, you get an empty buffer (actually NO buffer) when
EOF is reached.
If you consider an empty buffer to be one with just a newline (and
terminator) then you might see that and you have to test for it
yourself.

It might have been nice if the fgets interface included returning the
length of the data put in the buffer, so somewhat agree on that point
(the "non-empty" condition.)

The full condition is easy enough to check since the newline is not in
the buffer in that case. (or would this be an "overflow" condition in
your view?).

most of the time, I'm not sure these return conditions (non-empty,
full, ...) are really useful.

> --
> Flash Gordon
> Living in interesting times.
> Although my email address says spam, it is real and I read it.


Thanks again for the watchful eye.
Ed.

 
Reply With Quote
 
 
 
 
Flash Gordon
Guest
Posts: n/a
 
      12-23-2005
Ed Prochak wrote:
> Flash Gordon wrote:
>> 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.

>
> Empty buffer is what you might have After the return.


Not if the user hits another key fast enough. Also, that does not help
you check if there is an empty buffer, because if you call fgets it will
wait until a line has been entered.

> This is not
> realtime I/O or raw terminal I/O. If the OP wants that they need to
> look elsewhere.


Agreed. However, what pemo said, and I agree with, is that it would be
nice to be able to test if input is available.

>> Your use of getchar is completely wrong, since it
>> returns EOF, not 0, or either end-of-file or error.

>
> You are right. I did it quickly and should have double checked (I did
> put in EOF originally but then for some reaon I thought it wasn simpler
> this way. Too much thinking). Thanks for the catch.


We all make mistakes

>> You don't attempt to
>> distinguish between an error and end-of-file (which can be done).

>
> He did not ask about error checking, that comes outside the loop.


Yes, but your loop, which you suggested would detect end of file, will
report end of file when it was actually an error condition, so it does
not meet what I read as being the specification.

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

>> Obviously not.

>
> I got sloppy on getchar(). my apologies to all.
>> 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.

>
> in the getchar() case there is no buffer.


Yes there is in general. Normally stdin is line buffered so even you use
getchar it *still* won't return until the user presses return.

> in the fgets() case, you get an empty buffer (actually NO buffer) when
> EOF is reached.
> If you consider an empty buffer to be one with just a newline (and
> terminator) then you might see that and you have to test for it
> yourself.


No, I consider an empty buffer to be there is no input sitting there
ready to be returned immediately if you call an input function.

> It might have been nice if the fgets interface included returning the
> length of the data put in the buffer, so somewhat agree on that point
> (the "non-empty" condition.)


That is absolutely nothing to do with the problem.

The problem is, will the input function (getchar, fgets or whatever)
return immediately if I call it or will it sit there until some data (or
an error or end-of-file) arrives from else where, be that else-where a
file, serial port, pipe or whatever stdin is fetching from.

> The full condition is easy enough to check since the newline is not in
> the buffer in that case. (or would this be an "overflow" condition in
> your view?).
>
> most of the time, I'm not sure these return conditions (non-empty,
> full, ...) are really useful.


They are very useful if you want your program to process input if there
is input available but get on with something else if no input is
available, and this is not that uncommon a requirement.
--
Flash Gordon
Living in interesting times.
Although my email address says spam, it is real and I read it.
 
Reply With Quote
 
Jack Davis
Guest
Posts: n/a
 
      12-24-2005
Maybe this is the solution.

#include <stdio.h>

int main ()
{
int num[4],i;
char ch;
do{
i=0; // Remember this
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");
getchar();
scanf ("%c", &ch);
} while (ch=='y');
return 0;
}

getchar is used to remove \n from stdin

 
Reply With Quote
 
Flash Gordon
Guest
Posts: n/a
 
      12-24-2005
Jack Davis wrote:
> Maybe this is the solution.


Solution to what? Provide context please, see
http://cfaj.freeshell.org/google/

> #include <stdio.h>
>
> int main ()
> {
> int num[4],i;
> char ch;
> do{
> i=0; // Remember this
> 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");
> getchar();
> scanf ("%c", &ch);
> } while (ch=='y');
> return 0;
> }
>
> getchar is used to remove \n from stdin


What if the user enters:
5 pounds
I don't think you will get the correct result then. As has been stated
many times here, the best way is generally to use fgets to read the line
and then parse it afterwards.
--
Flash Gordon
Living in interesting times.
Although my email address says spam, it is real and I read it.
 
Reply With Quote
 
Chuck F.
Guest
Posts: n/a
 
      12-24-2005
Flash Gordon wrote:
> Jack Davis wrote:
>

.... snip code using scanf interactively ...
>>
>> getchar is used to remove \n from stdin

>
> What if the user enters: 5 pounds I don't think you will get the
> correct result then. As has been stated many times here, the
> best way is generally to use fgets to read the line and then
> parse it afterwards.


The general problem with that is that you must then provide a
buffer, and must still contend with the possibility of unabsorbed
line endings. It is possible to use scanf safely for numeric input
in interactive situations as follows:

int flushln(FILE *f)
{
int ch;

while ('\n' != (ch = getc(f)) && (EOF != ch)) continue;
return ch;
} /* flushln */

with this little thing available, you can now avoid all buffers for
numeric input with:

int thingwanted;

....
printf("%s", someprompt); fflush(stdout);
if (1 != scanf("%d", &thingwanted)) {
/* input error, take action */
}
else {
flushln(stdin);
/* use the data */
}

The critical thing is that scanf only attempts one item, so that
its return value is easily interpreted. Scanf also always leaves
the terminating char in the input stream, so flushln (barring EOF
or error) will always have a '\n' to terminate on.

Note that the caller to flushln can still detect EOF or error.

--
"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." - Keith Thompson
More details at: <http://cfaj.freeshell.org/google/>
 
Reply With Quote
 
Chris Torek
Guest
Posts: n/a
 
      12-24-2005
In article <(E-Mail Removed)>
Chuck F. <(E-Mail Removed)> wrote:
>The general problem with [fgets+sscanf] is that you must then provide a
>buffer, and must still contend with the possibility of unabsorbed
>line endings.


Of course, one can use your ggets(), plus sscanf().

>It is possible to use scanf safely for numeric input in
>interactive situations [using a line-eating getc-loop function and]
> printf("%s", someprompt); fflush(stdout);
> if (1 != scanf("%d", &thingwanted)) {
> /* input error, take action */
> }
> else {
> flushln(stdin);
> /* use the data */
> }
>
>The critical thing is that scanf only attempts one item, so that
>its return value is easily interpreted. Scanf also always leaves
>the terminating char in the input stream, so flushln (barring EOF
>or error) will always have a '\n' to terminate on.


This still has one undesirable behavior. Suppose the above asks
for a number, and (on a conventional system) we have the following
on a screen, with "_" representing the cursor input:

Pick a number: _

The user now presses the ENTER key (or the RETURN key, depending
on the keyboard). The screen now shows:

Pick a number:
_

The user presses ENTER many more times. The screen now shows:

_

What is the machine doing?

(The answer is: it is consuming white-space previous to the "%d"
conversion. Most scanf formats begin by consuming white-space,
and it does not matter how many blank lines, or lines containing
nothing but blanks, are included at this point. They are all
consumed.)

Using fgets() (or ggets()), the program itself gets control back
at the point the user presses ENTER, and can re-print the prompt,
or handle "no number entered" in some suitable fashion.

The scanf family of functions simply behaves badly for interactive
input. If it were a kid, it would be getting a lump of coal for
Christmas. (This is also why the "sfio" library has a rather
different set of input directives. It is kind of a shame the C
Standards folks considered only the K&R scanf() and not the sfio
input functions.)
--
In-Real-Life: Chris Torek, Wind River Systems
Salt Lake City, UT, USA (4039.22'N, 11150.29'W) +1 801 277 2603
email: forget about it http://web.torek.net/torek/index.html
Reading email is like searching for food in the garbage, thanks to spammers.
 
Reply With Quote
 
Chuck F.
Guest
Posts: n/a
 
      12-24-2005
Chris Torek wrote:
> Chuck F. <(E-Mail Removed)> wrote:
>
>> The general problem with [fgets+sscanf] is that you must then
>> provide a buffer, and must still contend with the possibility
>> of unabsorbed line endings.

>
> Of course, one can use your ggets(), plus sscanf().
>
>> It is possible to use scanf safely for numeric input in
>> interactive situations [using a line-eating getc-loop function

.... snip ...
>>
>> The critical thing is that scanf only attempts one item, so
>> that its return value is easily interpreted. Scanf also
>> always leaves the terminating char in the input stream, so
>> flushln (barring EOF or error) will always have a '\n' to
>> terminate on.

>
> This still has one undesirable behavior. Suppose the above asks
> for a number, and (on a conventional system) we have the
> following on a screen, with "_" representing the cursor input:


.... snip discussion of white space absorption nuisance ...

Then you can use the following routines, which are probably more
efficient than loading the whole schmeer of scanf interpretation
anyhow. The following again avoids the assignment of a buffer.

(These are directed at the thread, not at Chris Torek, who knows
very well how to build bulletproof i/o routines)

(I also seem to remember something dodgy about inputting -INTMAX
with these)

#ifndef H_txtinput_h
#define H_txtinput_h
# ifdef __cplusplus
extern "C" {
# endif

#include <stdio.h>

/* These stream input routines are written so that simple
* conditionals can be used:
*
* if (readxint(&myint, stdin)) {
* do_error_recovery; normally_abort_to_somewhere;
* }
* else {
* do_normal_things; usually_much_longer_than_bad_case;
* }
*
* They allow overflow detection, and permit other routines to
* detect the character that terminated a numerical field. No
* string storage is required, thus there is no limitation on
* the length of input fields. For example, a number entered
* with a string of 1000 leading zeroes will not annoy these.
*
* The numerical input routines *NEVER* absorb a terminal '\n'.
* Thus a sequence such as:
*
* err = readxint(&myint, stdin);
* flushln(stdin);
*
* will always consume complete lines.
*
* They are also re-entrant, subject to the limitations of file
* systems. e.g interrupting readxint(v, stdin) operation with
* a call to readxwd(wd, stdin) would not be well defined, if
* the same stdin is being used for both calls. If ungetc is
* interruptible the run-time system is broken.
*/

/*--------------------------------------------------------------
* Skip all blanks on f. At completion getc(f) will return
* a non-blank character, which may be \n or EOF
*
* Skipblks returns the char that getc will next return, or EOF.
*/
int skipblks(FILE *f);

/*--------------------------------------------------------------
* Skip all whitespace on f, including \n, \f, \v, \r. At
* completion getc(f) will return a non-blank character, which
* may be EOF
*
* Skipblks returns the char that getc will next return, or EOF.
*/
int skipwhite(FILE *f);

/*--------------------------------------------------------------
* Read an unsigned value. Signal error for overflow or no
* valid number found. Returns true for error, false for noerror
*
* Skip all leading whitespace on f. At completion getc(f) will
* return the character terminating the number, which may be \n
* or EOF among others. Barring EOF it will NOT be a digit. The
* combination of error and the following getc returning \n
* indicates that no numerical value was found on the line.
*
* If the user wants to skip all leading white space including
* \n, \f, \v, \r, he should first call "skipwhite(f);"
*
* Peculiarity: This specifically forbids a leading '+' or '-'.
* Peculiarity: This forbids overflow, unlike C unsigned usage.
* on overflow, UINT_MAX is returned.
*/
int readxwd(unsigned int *wd, FILE *f);

/*--------------------------------------------------------------
* Read a signed value. Signal error for overflow or no valid
* number found. Returns true for error, false for noerror. On
* overflow either INT_MAX or INT_MIN is returned in *val.
*
* Skip all leading whitespace on f. At completion getc(f) will
* return the character terminating the number, which may be \n
* or EOF among others. Barring EOF it will NOT be a digit. The
* combination of error and the following getc returning \n
* indicates that no numerical value was found on the line.
*
* If the user wants to skip all leading white space including
* \n, \f, \v, \r, he should first call "skipwhite(f);"
*
* Peculiarity: an isolated leading '+' or '-' NOT immediately
* followed by a digit will return error and a value of 0, when
* the next getc will return that following non-digit. This is
* caused by the single level ungetc available.
*/
int readxint(int *val, FILE *f);

/*--------------------------------------------------------------
* Flush input through an end-of-line marker inclusive.
*/
void flushln(FILE *f);

# ifdef __cplusplus
}
# endif
#endif
/* End of txtinput.h */

/* ------------------------------------------------- *
* File txtinput.c *
* ------------------------------------------------- */

#include <limits.h> /* xxxx_MAX, xxxx_MIN */
#include <ctype.h> /* isdigit, isblank, isspace */
#include <stdio.h> /* FILE, getc, ungetc */
#include "txtinput.h"

#define UCHAR unsigned char

/* These stream input routines are written so that simple
* conditionals can be used:
*
* if (readxint(&myint, stdin)) {
* do_error_recovery; normally_abort_to_somewhere;
* }
* else {
* do_normal_things; usually_much_longer_than_bad_case;
* }
*
* They allow overflow detection, and permit other routines to
* detect the character that terminated a numerical field. No
* string storage is required, thus there is no limitation on
* the length of input fields. For example, a number entered
* with a string of 1000 leading zeroes will not annoy these.
*
* The numerical input routines *NEVER* absorb a terminal '\n'.
* Thus a sequence such as:
*
* err = readxint(&myint, stdin);
* flushln(stdin);
*
* will always consume complete lines.
*
* They are also re-entrant, subject to the limitations of file
* systems. e.g interrupting readxint(v, stdin) operation with
* a call to readxwd(wd, stdin) would not be well defined, if
* the same stdin is being used for both calls. If ungetc is
* interruptible the run-time system is broken.
*/

/*--------------------------------------------------------------
* Skip all blanks on f. At completion getc(f) will return
* a non-blank character, which may be \n or EOF
*
* Skipblks returns the char that getc will next return, or EOF.
*/
int skipblks(FILE *f)
{
int ch;

do {
ch = getc(f);
} while ((' ' == ch) || ('\t' == ch));
/* while (isblank((UCHAR)ch)); */ /* for C99 */
return ungetc(ch, f);
} /* skipblks */

/*--------------------------------------------------------------
* Skip all whitespace on f, including \n, \f, \v, \r. At
* completion getc(f) will return a non-blank character, which
* may be EOF
*
* Skipwhite returns the char that getc will next return, or EOF.
*/
int skipwhite(FILE *f)
{
int ch;

do {
ch = getc(f);
} while (isspace((UCHAR)ch));
return ungetc(ch, f);
} /* skipwhite */

/*--------------------------------------------------------------
* Read an unsigned value. Signal error for overflow or no
* valid number found. Returns true for error, false for noerror
*
* Skip all leading whitespace on f. At completion getc(f) will
* return the character terminating the number, which may be \n
* or EOF among others. Barring EOF it will NOT be a digit. The
* combination of error and the following getc returning \n
* indicates that no numerical value was found on the line.
*
* If the user wants to skip all leading white space including
* \n, \f, \v, \r, he should first call "skipwhite(f);"
*
* Peculiarity: This specifically forbids a leading '+' or '-'.
* Peculiarity: This forbids overflow, unlike C unsigned usage.
* on overflow, UINT_MAX is returned.
*/
int readxwd(unsigned int *wd, FILE *f)
{
unsigned int value, digit;
int status;
int ch;

#define UWARNLVL (UINT_MAX / 10U)
#define UWARNDIG (UINT_MAX - UWARNLVL * 10U)

value = 0; /* default */
status = 1; /* default error */

do {
ch = getc(f);
} while ((' ' == ch) || ('\t' == ch)); /* skipblanks */
/* while (isblank((UCHAR)ch)); */ /* for C99 */

if (!(EOF == ch)) {
if (isdigit((UCHAR)ch)) /* digit, no error */
status = 0;
while (isdigit((UCHAR)ch)) {
digit = (unsigned) (ch - '0');
if ((value < UWARNLVL) ||
((UWARNLVL == value) && (UWARNDIG >= digit)))
value = 10 * value + digit;
else { /* overflow */
status = 1;
value = UINT_MAX;
}
ch = getc(f);
} /* while (ch is a digit) */
}
*wd = value;
ungetc(ch, f);
return status;
} /* readxwd */

/*--------------------------------------------------------------
* Read a signed value. Signal error for overflow or no valid
* number found. Returns true for error, false for noerror. On
* overflow either INT_MAX or INT_MIN is returned in *val.
*
* Skip all leading whitespace on f. At completion getc(f) will
* return the character terminating the number, which may be \n
* or EOF among others. Barring EOF it will NOT be a digit. The
* combination of error and the following getc returning \n
* indicates that no numerical value was found on the line.
*
* If the user wants to skip all leading white space including
* \n, \f, \v, \r, he should first call "skipwhite(f);"
*
* Peculiarity: an isolated leading '+' or '-' NOT immediately
* followed by a digit will return error and a value of 0, when
* the next getc will return that following non-digit. This is
* caused by the single level ungetc available.
*/
int readxint(int *val, FILE *f)
{
unsigned int value;
int status, negative;
int ch;

*val = value = 0; /* default */
status = 1; /* default error */
negative = 0;

do {
ch = getc(f);
} while ((' ' == ch) || ('\t' == ch)); /* skipwhite */
/* while (isblank((UCHAR)ch)); */ /* for C99 */

if (!(EOF == ch)) {
if (('+' == ch) || ('-' == ch)) {
negative = ('-' == ch);
ch = getc(f); /* absorb any sign */
}

if (isdigit((UCHAR)ch)) { /* digit, no error */
ungetc(ch, f);
status = readxwd(&value, f);
ch = getc(f); /* This terminated readxwd */
}

if (negative && (value < UINT_MAX) &&
((value - 1) <= -(1 + INT_MIN))) *val = -value;
else if (value <= INT_MAX) *val = value;
else { /* overflow */
status = 1;
if (value)
if (negative) *val = INT_MIN;
else *val = INT_MAX;
}
}
ungetc(ch, f);
return status;
} /* readxint */

/*-----------------------------------------------------
* Flush input through an end-of-line marker inclusive.
*/
void flushln(FILE *f)
{
int ch;

do {
ch = getc(f);
} while (('\n' != ch) && (EOF != ch));
} /* flushln */

/* End of txtinput.c */

--
"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." - Keith Thompson
More details at: <http://cfaj.freeshell.org/google/>
 
Reply With Quote
 
those who know me have no need of my name
Guest
Posts: n/a
 
      12-27-2005
in comp.lang.c i read:

all your casts of ch to UCHAR are a waste of time -- mine to see it and
yours to write it; heck even the compiler's, and the cpu's if code was
emitted -- as the source of ch's value is getc, which provides exactly the
value semantics you (redundantly) specify with the cast.

in the readxwd and readxint functions you initially loop to skip blanks, yet
earlier you defined a blank skipping function -- why aren't you using it?
then again you specifically state that the user should skip blanks prior to
calling the functions if that is their desire, so those loops seem contrary.

> digit = (unsigned) (ch - '0');


this cast is also unnecessary, not the least because ch passed an isdigit
test, but also because digit has type unsigned.

--
a signature
 
Reply With Quote
 
Ed Prochak
Guest
Posts: n/a
 
      12-27-2005

Flash Gordon wrote:
> Ed Prochak wrote:
> > Flash Gordon wrote:
> >> Ed Prochak wrote:
> >>> pemo wrote:

[]
> > Empty buffer is what you might have After the return.

>
> Not if the user hits another key fast enough. Also, that does not help
> you check if there is an empty buffer, because if you call fgets it will
> wait until a line has been entered.
>
> > This is not
> > realtime I/O or raw terminal I/O. If the OP wants that they need to
> > look elsewhere.

>
> Agreed. However, what pemo said, and I agree with, is that it would be
> nice to be able to test if input is available.
>

[]

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

> >
> > in the getchar() case there is no buffer.

>
> Yes there is in general. Normally stdin is line buffered so even you use
> getchar it *still* won't return until the user presses return.


I was speaking of the user's buffer, not the systems buffer. Again, If
you want raw I/O you'll have to look at other functions, outside the C
standard.

>
> > in the fgets() case, you get an empty buffer (actually NO buffer) when
> > EOF is reached.
> > If you consider an empty buffer to be one with just a newline (and
> > terminator) then you might see that and you have to test for it
> > yourself.

>
> No, I consider an empty buffer to be there is no input sitting there
> ready to be returned immediately if you call an input function.


No input available is EOF. The user hung up the line, closed his
terminal window, or powered down his terminal. You are waiting on a
user, a person. human response times are measured in seconds or longer.
The computer is operating in microseconds and shorter. In the end the
computer always has to wait.

And again, if you want raw I/O look elsewhere. Besides games there are
very few applications (e.g., factory controls or embedded devices) that
need raw I/O. I've done these types of applications. Usually they don't
use stdio functions. This type of operation is often OS dependent.

>
> > It might have been nice if the fgets interface included returning the
> > length of the data put in the buffer, so somewhat agree on that point
> > (the "non-empty" condition.)

>
> That is absolutely nothing to do with the problem.
>
> The problem is, will the input function (getchar, fgets or whatever)
> return immediately if I call it or will it sit there until some data (or
> an error or end-of-file) arrives from else where, be that else-where a
> file, serial port, pipe or whatever stdin is fetching from.


yes that's the differrence. I don't see that as a problem 99% of the
time, so why should the interface be complicated to improve the few
cases that do need it.

here's a question for you: want your disc I/O unbuffered too?
(oops, sorry but you didn't read that last data block fast enough, it's
gone because the next block is ready right NOW)

Be careful what you ask for, you just might get it. 8^)

>
> > The full condition is easy enough to check since the newline is not in
> > the buffer in that case. (or would this be an "overflow" condition in
> > your view?).
> >
> > most of the time, I'm not sure these return conditions (non-empty,
> > full, ...) are really useful.

>
> They are very useful if you want your program to process input if there
> is input available but get on with something else if no input is
> available, and this is not that uncommon a requirement.


There are ways of dealing with this that don't invlove complicating the
C standard I/O interface.

I disagree that this is a common requirement. Give some examples of
applications where this is clearly a requirement (and not just a
nice-to-have feature). Does your new checkbook program really have
anything useful to do while the user is entering the dollar amount of
the deposit?

Finally, let's be clear: which buffer do you really want to know about?
the buffer in your keyboard hardware?
the keyboard driver buffer?
the OS I/O buffers?
your application's window buffer?
your application's C I/O buffer?
your application's buffer?
Which one?
Do you see that changing just the C I/O functions might not solve your
problem?

Ed

 
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