I'm studying about how scanf works.
After scanned other type variable, char variable stores a white-space('\n') by getchar() or scanf("%c").
To prevent this, they should clear buffer. And I did it with rewind(stdin)
though stdin is rewinded previous input value is keeping in buffer.
and I can do something with the previous value normally.(nothing runtime errors)
but if I try scanf again, scanf will scan a new value even there is a normal value in buffer.
how does scanf determine if it should scan a new value?
I found this mechanism with below code.
#include <stdio.h>
#define p stdin
int main() {
int x;
char ch;
void* A, * B, * C, * D, * E;
A = p->_Placeholder;
printf("A : %p\n", A);//first time, it shows 0000
scanf_s("%d", &x);
B = p->_Placeholder;
printf("B : %p\n", B);//after scanned something, I think it's begin point of buffer which is assigned for this process
rewind(stdin);//rewind _Placeholder
C = p->_Placeholder;
printf("C : %p\n", C);//it outputs the same value as B - length of x
D = p->_Placeholder;
printf("D : %c\n", ((char*)D)[0]);//the previous input value is printed successfully without runtime error. it means buffer is not be cleared by scanf
scanf_s("%c", &ch, 1);//BUT scanf knows the _Placeholder is not pointing new input value, so it will scan a new value from console. How??
E = p->_Placeholder;
printf("E : %p\n", E);
printf("ch : %c\n", ch);
}
You have at least three misunderstandings:
"char variable stores a white-space"
rewind(stdin) clears the buffer
_Placeholder tells you something interesting about how scanf handles whitespace
But, I'm sorry, none of these are true.
Let's review how scanf actually handles whitespace. We start with two important pieces of background information:
The newline character, \n, is in most respects an ordinary whitespace character. It occupies space in the input buffer just like any other character. It arrives in the input buffer when you press the Enter key.
When it's done parsing a %-directive, scanf always leaves unparsed input on the input stream.
Suppose you write
int a, b;
scanf("%d%d", &a, &b);
Suppose you run that code and type, as input
12 34
and then hit the Enter key. What happens?
First, the input stream (stdin) now contains six characters:
"12 34\n"
scanf first processes the first of the two %d directives you gave it. It scans the characters 1 and 2, converting them to the integer 12 and storing it in the variable a. It stops reading at the first non-digit character it sees, which is the space character between 2 and 3. The input stream is now
" 34\n"
Notice that the space character is still on the input stream.
scanf next processes the second %d directive. It doesn't immediately find a digit character, because the space character is still there. But that's okay, because like most (but not quite all) scanf format directives, %d has a secret extra power: it automatically skips whitespace characters before reading and converting an integer. So the second %d reads and discards the space character, then reads the characters 3 and 4 and converts them to the integer 34, which it stores in the variable b.
Now scanf is done. The input stream is left containing just the newline:
"\n"
Next, let's look at a slightly different — although, as we'll see, actually very similar — example. Suppose you write
int x, y;
scanf("%d", &x);
scanf("%d", &y);
Suppose you run that code and type, as input
56
78
(where that's on two lines, meaning that you hit Enter twice).
What happens now?
In this case, the input stream will end up containing these six characters:
"56\n78\n"
The first scanf call has a %d directive to process. It scans the characters 5 and 6, converting them to the integer 56 and storing it in the variable x. It stops reading at the first non-digit character it sees, which is the newline after the 6. The input stream is now
"\n78\n"
Notice that the newline character (both newline characters) are still on the input stream.
Now the second scanf call runs. It, too, has a %d directive to process. The first character on the input stream is not a digit: it's a newline. But that's okay, because %d knows how to skip whitespace. So it reads and discards the newline character, then reads the characters 7 and 8 and converts them to the integer 78, which it stores in the variable y.
Now the second scanf is done. The input stream is left containing just the newline:
"\n"
This may all have made sense, may have seemed unsurprising, may have left you feeling, "Okay, so what's the big deal?" The big deal is this: In both examples, the input was left containing that one, last newline character.
Suppose, later in your program, you have some other input to read. We now come to a hugely significant decision point:
If the next input call is another call to scanf, and if it involves one of the (many) format specifiers that has the secret extra power of also skipping whitespace, that format specifier will skip the newline, then do its job of scanning and converting whatever input comes after the newline, and the program will work as you expect.
But if the next input call is not a call to scanf, or if it's a call to scanf that involves one of the few input specifiers that does not have the secret extra power, the newline will not be "skipped", instead it will be read as actual input. If the next input call is getchar, it will read and return the newline character. If the next input call is fgets, it will read and return a blank line. If the next input call is scanf with the %c directive, it will read and return the newline. If the next input call is scanf with the %[^\n] directive, it will read an empty line. (Actually %[^\n] will read nothing in this case, because it leaves the \n still on the input.)
It's in the second case that the "extra" whitespace causes a problem. It's in the second case that you may find yourself wanting to explicitly "flush" or discard the extra whitespace.
But it turns out that the problem of flushing or discarding the extra whitespace left behind by scanf is a remarkably stubborn one. You can't portably do it by calling fflush. You can't portably do it by calling rewind. If you care about correct, portable code, you basically have three choices:
Write your own code to explicitly read and discard "extra" characters (typically, up to and including the next newline).
Don't try to intermix scanf and other calls. Don't call scanf and then, later, try to call getchar or fgets. If you call scanf and then, later, call scanf with one of the directives (such as "%c") that lacks the "secret extra power", insert an extra space before the format specifier to cause whitespace to be skipped. (That is, use " %c" instead of "%c".)
Don't use scanf at all — do all your input in terms of fgets or getchar.
See also What can I use for input conversion instead of scanf?
Addendum: scanf's handling of whitespace can often seem puzzling. If the above explanation isn't sufficient, it may help to look at some actual C code detailing how scanf works inside. (The code I'm going to show obviously isn't the exact code that's behind your system's implementation, but it will be similar.)
When it comes time for scanf to process a %d directive, you might imagine it will do something like this. (Be forewarned: this first piece of code I'm going to show you is incomplete and wrong. It's going to take me three tries to get it right.)
c = getchar();
if(isdigit(c)) {
int intval;
intval = c - '0';
while(isdigit(c = getchar())) {
intval = 10 * intval + (c - '0');
}
*next_pointer_arg = intval;
n_vals_converted++;
} else {
/* saw no digit; processing has failed */
return n_vals_converted;
}
Let's make sure we understand everything that's going on here. We've been told to process a %d directive. We read one character from the input by calling getchar(). If that character is a digit, it's the first of possibly several digits making up an integer. We read characters and, as long as they're digits, we add them to the integer value, intval, we're collecting. The conversion involves subtracting the constant '0', to convert an ASCII character code to a digit value, and successive multiplication by 10. Once we see a character that's not a digit, we're done. We store the converted value into the pointer handed to us by our caller (here schematically but approximately represented by the pointer value next_pointer_arg), and we add one to a variable n_vals_converted keeping count of how many values we've successfully scanned and converted, which will eventually be scanf's return value.
If, on the other hand, we don't even see one digit character, we've failed: we return immediately, and our return value is the number of values we've successfully scanned and converted so far (which may well be 0).
But there is actually a subtle bug here. Suppose the input stream contains
"123x"
This code will successfully scan and convert the digits 1, 2, and 3 to the integer 123, and store this value into *next_pointer_arg. But, it will have read the character x, and after the call to isdigit in the loop while(isdigit(c = getchar())) fails, the x character will have effectively been discarded: it is no longer on the input stream.
The specification for scanf says that it is not supposed to do this. The specification for scanf says that unparsed characters are supposed to be left on the input stream. If the user had actually passed the format specifier "%dx", that would mean that, after reading and parsing an integer, a literal x is expected in the input stream, and scanf is going to have to explicitly read and match that character. So it can't accidentally read and discard the x in the process of parsing a %d directive.
So we need to modify our hypothetical %d code slightly. Whenever we read a character that turns out not to be an integer, we have to literally put it back on the input stream, for somebody else to maybe read later. There's actually a function in <stdio.h> to do this, sort of the opposite of getc, called ungetc. Here is a modified version of the code:
c = getchar();
if(isdigit(c)) {
int intval;
intval = c - '0';
while(isdigit(c = getchar())) {
intval = 10 * intval + (c - '0');
}
ungetc(c, stdin); /* push non-digit character back onto input stream */
*next_pointer_arg = intval;
n_vals_converted++;
} else {
/* saw no digit; processing has failed */
ungetc(c, stdin);
return n_vals_converted;
}
You will notice that I have added two calls to ungetc, in both places in the code where, after calling getchar and then isdigit, the code has just discovered that it has read a character that is not a digit.
It might seem strange to read a character and then change your mind, meaning that you have to "unread" it. It might make more sense to peek at at an upcoming character (to determine whether or not it's a digit) without reading it. Or, having read a character and discovered that it's not a digit, if the next piece of code that's going to process that character is right here in scanf, it might make sense to just keep it in the local variable c, rather than calling ungetc to push it back on the input stream, and then later calling getchar to fetch it from the input stream a second time. But, having called out these other two possibilities, I'm just going to say that, for now, I'm going to plough ahead with the example that uses ungetc.
So far I've shown the code that you might have imagined lay behind scanf's processing of %d. But the code I've shown so far is still significantly incomplete, because it does not show the "secret extra power". It starts looking for digit characters right away; it doesn't do any skipping of leading whitespace.
Here, then, is my third and final sample fragment of %d-processing code:
/* skip leading whitespace */
while(isspace(c = getchar())) {
/* discard */
}
if(isdigit(c)) {
int intval;
intval = c - '0';
while(isdigit(c = getchar())) {
intval = 10 * intval + (c - '0');
}
ungetc(c, stdin); /* push non-digit character back onto input stream */
*next_pointer_arg = intval;
n_vals_converted++;
} else {
/* saw no digit; processing has failed */
ungetc(c, stdin);
return n_vals_converted;
}
That initial loop reads and discards characters as long as they're whitespace. Its form is very similar to the later loop that reads and processes characters as long as they're digits. The initial loop will read one more character than it seems like it should: when the isspace call fails, that means that it has just read a non whitespace character. But that's okay, because we were just about to read a character to see if it was the first digit.
[Footnotes: This code is still far from perfect. One pretty significant problem is that it doesn't have any checks for an EOF coming along in the middle of its parsing. Another problem is that it doesn't look for - or + before the digits, so it won't handle negative numbers. Yet another, more obscure problem is that, ironically, obvious-looking calls like isdigit(c) are not always correct — strictly speaking they need to be somewhat cumbersomely rendered as isdigit((unsigned char)c).]
If you're still with me, my point in all this is to illustrate these two points in a concrete way:
The reason %d is able to automatically skip leading whitespace is because (a) the specification says it's supposed to and (b) it has explicit code to do so, as my third example illustrates.
The reason scanf always leaves unprocessed input (that is, input that comes after the input it does read and process) on the input stream is because (a) again, the specification says it's supposed to and (b) its code is typically sprinkled with explicit calls to ungetc, or the equivalent, to make sure that every unprocessed character remains on the input, as my second example illustrates.
There are some problems with you approach:
you use an undocumented, implementation specific member of the FILE object _Placeholder which may or may not be available on different platforms and whose contents are implementation specific anyway.
you use scanf_s(), which is a Microsoft specific so-called secure version of scanf(): this function is optional and may not be available on all platforms. Furthermore, Microsoft's implementation does not conform to the C Standard: for example the size argument passed after &ch is documented in VS with a type of UINT whereas the C Standard specifies it as a size_t, which on 64-bit versions of Windows has a different size.
scanf() is quite tricky to use: even experienced C programmers get bitten by its many quirks and pitfalls. In your code, you test %d and %c, which behave very differently:
for %d, scanf() will first read and discard any white space characters, such as space, TAB and newlines, then read an optional sign + or -, it then expects to read at least one digit and stop when it gets a byte that is not a digit and leave this byte in the input stream, pushing it back with ungetc() or equivalent. If no digits can be read, the conversion fails and the first non digit character is left pending in the input stream, but the previous bytes are not necessarily pushed back.
processing %c is much simpler: a single byte is read and stored into the char object or the conversion fails if the stream is at end of file.
Processing %c after %d is tricky if the input stream is bound to a terminal as the user will enter a newline after the number expected for %d and this newline will be read immediately for the %c. The program can ignore white space before the byte expected for %c by inserting a space before %c in the format string: res = scanf(" %c", &ch);
To better understand the behavior of scanf(), you should output the return value of each call and the stream current position, obtained via ftell(). It is also more reliable to first set the stream to binary mode for the return value of ftell() to be exactly the number of bytes from the beginning of the file.
Here is a modified version:
#include <stdio.h>
#ifdef _MSC_VER
#include <fcntl.h>
#include <io.h>
#endif
int main() {
int x, res;
char ch;
long A, B, C, D;
#ifdef _MSC_VER
_setmode(_fileno(stdin), _O_BINARY);
#endif
A = ftell(stdin);
printf("A : %ld\n", A);
x = 0;
res = scanf_s("%d", &x);
B = ftell(stdin);
printf("B : %ld, res=%d, x=%d\n", B, res, x);
rewind(stdin);
C = ftell(stdin);
printf("C : %ld\n", C);
ch = 0;
res = scanf_s("%c", &ch, 1);
D = ftell(stdin);
printf("D : %ld, res=%d, ch=%d (%c)\n", D, res, ch, ch);
return 0;
}
Here's some code that illustrates the behavior of the %d conversion specifier; it may help understand how that aspect of scanf works. This isn't how it's actually implemented anywhere, but it follows the same rules (Updated to handle leading +/- sign, checks for overflow, etc).
#include <stdio.h>
#include <ctype.h>
#include <errno.h>
#include <limits.h>
/**
* Mimics the behavior of the scanf %d conversion specifier.
* Skips over leading whitespace, then reads and converts
* decimal digits up to the next non-digit character.
*
* Returns EOF if no non-whitespace characters are
* seen before EOF.
*
* Returns 0 if the first non-whitespace character
* is not a digit.
*
* Returns 1 if at least one decimal digit was
* read and converted.
*
* Stops reading on the first non-digit
* character, pushes that character back
* on the input stream.
*
* In the event of a signed integer overflow,
* sets errno to ERANGE.
*/
int scan_to_int( FILE *stream, int *value )
{
int conv = 0;
int tmp = 0;
int c;
int sign = 0;
/**
* Skip over leading whitespace
*/
while( ( c = fgetc( stream ) ) != EOF && isspace( c ) )
; // empty loop
/**
* If we see end of file before any non-whitespace characters,
* return EOF.
*/
if ( c == EOF )
return c;
/**
* Account for a leading sign character.
*/
if ( c == '-' || c == '+' )
{
sign = c;
c = fgetc( stream );
}
/**
* As long as we see decimal digits, read and convert them
* to an integer value. We store the value to a temporary
* variable until we're done converting - we don't want
* to update value unless we know the operation was
* successful
*/
while( c != EOF && isdigit( c ) )
{
/**
* Check for overflow. While setting errno on overflow
* isn't required by the C language definition, I'm adding
* it anyway.
*/
if ( tmp > INT_MAX / 10 - (c - '0') )
errno = ERANGE;
tmp = tmp * 10 + (c - '0');
conv = 1;
c = fgetc( stream );
}
/**
* Push the last character read back onto the input
* stream.
*/
if ( c != EOF )
ungetc( c, stream );
/**
* If we read a sign character (+ or -) but did not have a
* successful conversion, then that character was not part
* of a numeric string and we need to put it back on the
* input stream in case it's part of a non-numeric input.
*/
if ( sign && !conv )
ungetc( sign, stream );
/**
* If there was a successful read and conversion,
* update the output parameter.
*/
if ( conv )
*value = tmp * (sign == '-' ? -1 : 1);
/**
* Return 1 if the read was successful, 0 if there
* were no digits in the input.
*/
return conv;
}
/**
* Simple test program - attempts to read 1 integer from
* standard input and display it. Display any trailing
* characters in the input stream up to and including
* the next newline character.
*/
int main( void )
{
int val;
int r;
errno = 0;
/**
* Read the next item from standard input and
* attempt to convert it to an integer value.
*/
if ( (r = scan_to_int( stdin, &val )) != 1 )
printf( "Failed to read input, r = %d\n", r );
else
printf( "Read %d%s\n", val, errno == ERANGE ? " (overflow)" : "" );
/**
* If we didn't hit EOF, display the remaining
* contents of the input stream.
*/
if ( r != EOF )
{
fputs( "Remainder of input stream: {", stdout );
int c;
do {
c = fgetc( stdin );
switch( c )
{
case '\a': fputs( "\\a", stdout ); break;
case '\b': fputs( "\\b", stdout ); break;
case '\f': fputs( "\\f", stdout ); break;
case '\n': fputs( "\\n", stdout ); break;
case '\r': fputs( "\\r", stdout ); break;
case '\t': fputs( "\\t", stdout ); break;
default: fputc( c, stdout ); break;
}
} while( c != '\n' );
fputs( "}\n", stdout );
}
return 0;
}
Some examples - first, we signal EOF (in my case, by typing Ctrl-D):
$ ./convert
Failed to read input, r = -1
Next, we pass in a non-numeric string:
$ ./convert
abcd
Failed to read input, r = 0
Remainder of input stream: {abcd\n}
Since nothing was converted, the remainder of the input stream contains everything we typed (including the newline from hitting Enter).
Next, a numeric string with non-numeric trailing characters:
$ ./convert
12cd45
Read 12
Remainder of input stream: {cd45\n}
We stopped reading at 'c' - only the leading 12 is read and converted.
Several numeric strings separated by whitespace - only the first string is converted:
$ ./convert
123 456 789
Read 123
Remainder of input stream: {\t456\t789\n}
And a numeric string with leading whitespace:
$ ./convert
12345
Read 12345
Remainder of input stream: {\n}
Handle leading signs:
$ ./convert
-123abd
Read -123
Remainder of input stream: {abd\n}
$ ./convert
+456
Read 456
Remainder of input stream: {\n}
$ ./convert
-abcd
Failed to read input, r = 0
Remainder of input stream: {-abcd\n}
And, finally, we add an overflow check - note that scanf is not required to check for overflow by the C language standard, but I figured it was a useful thing to do:
$ ./convert
123456789012345678990012345667890
Read -701837006 (overflow)
Remainder of input stream: {\n}
%d, %i, %f, %s, etc., all skip over leading whitespace, since whitespace is not meaningful in those cases except to act as a separator between inputs. %c and %[ do not skip over leading whitespace, because it may be meaningful for those particular conversions (there are times when you want to know whether the character you just read is a space, or a tab, or a newline).
As Steve points out, whitespace handling in C stdio routines is and always has been a thorny problem, and no one solution always works the best, especially since different library routines handle it differently.
I got this piece of code
#include<stdio.h>
#include <stdlib.h>
int main()
{
int i;
int number, S;
float MO;
S = 0;
for(i=0;i<10;i++)
{
printf("AAA %d\n", i );
scanf("%d\n", &number);
S = S + number;
}
MO = S/10;
printf("%d , %f \n",S , MO );
return 0;
}
when the execution starts, AAA 0 is printed.I then give my first number.After that, i am expecting to see AAA 1 , but this will be printed only after i give my second number.
Checked this here
C/C++ printf() before scanf() issue
but seems i can get none of these solutions work for me
The answers claiming that this has something to do with flushing input or output are wrong. The problem has nothing to do with this. The appearance of the \n character at the end of the scanf() template string instructs scanf() to match and discard whitespace characters. It will do so until a non-whitespace character is encountered, or end-of-file is reached. The relevant part of the C11 Standard is §7.21.6.2 5:
A directive composed of white-space character(s) is executed by
reading input up to the first non-white-space character (which remains
unread), or until no more characters can be read. The directive never
fails.
In OP's case, a second number must be placed in the input stream so that the first can be assigned. The second number then remains in the input stream until the next call to scanf(). In the case of the example given by Stephan Lechner, taking input from a file, there is a number in the input stream after each number to be assigned, until the last number (if there are exactly ten numbers), and then the EOF causes scanf() to return. Note that OP could also have signalled EOF from the keyboard after each input. Or, OP could enter all numbers on one line, with an extra number to signal end of input:
1 2 3 4 5 6 7 8 9 10 11
The solution is simply to remove the \n from the end of the scanf() template string. Whitespace characters at the end of such a template string are tricky, and almost never what is actually desired.
Just remove the \n from the scanf format string:
scanf("%d", &number);
"\n" waits for non-white-space. Instead use scanf("%d", &number) #Michael Walz and check its return value.
Let us break down scanf("%d\n", &number);
"%d" Scan for numeric text. This specifier will allow leading white-space. Once some non-numeric character is found, put that character back into stdin. If valid numeric text for an integer was found, convert to an int and save to number.
"\n" Scan and discard 0 or more white-spaces such as '\n', ' ', and others. Continue scanning until non-white-space is encountered, put that character back into stdin.
Now return the number of fields scanned (1).
Notice step 2. User had to type in data after the Return or '\n' to get scanf() to return.
The issue is with the buffering of stdout which doesn't force a flush unless a \n is in the output or fflush is called specifically
I'm just asking what does the getchar do in this code and how does it work? I don't understand why the getchar affects the code, to me it seems as if its just getting the value but nothing is being done with the value.
int c=0;
while (c>=0)
{
scanf("%d", &c);
getchar();
}
Some possibilities of why getchar() might have been used there:
1) If it's done to ignore whitespaces (typically used when scanning chars with %c), it's not needed here because %d ignores whitespaces anyway.
2) Other possibility is that after this loop, some further scanning is done where the last \n left by the last call to scanf() might be a problem. So, getchar() might be used to ignore it.
3) In case you enter characters do not match %d, scanf() will fail. In that the characters you entered are left in the input stream and you'll never be able to read an int again (For example, if you input abcdddgdfg without that getchar() call). So, getchar() here will consume all those
chars (one per iteration) and eventually you'll be able to read int (using %d) again.
But this is all really not needed; it's just an attempt to fix flaws of scanf(). Reading inputs using scanf() and getting it correct is really difficult. That's why it's always recommended to use fgets() and parse using sscanf() or using strto*() functions if you are just scanning integers.
See: Why does everyone say not to use scanf? What should I use instead?
In this code, getchar is being called for its side effects: it reads a character from standard input and throws it away.
Probably this is reading input from the user. scanf will consume a number, but leave the newline character after the number untouched. The getchar consumes the newline and throws it away. This isn't strictly necessary in this loop, because the next scanf will skip over whitespace to find the next number, but it might be useful if the code after the loop isn't expecting to have a newline as the first thing on stdin.
This code is buggy, because it doesn't check for EOF, because it doesn't do anything sensible when the input is not a number or when there's more text on the line after the number, and because it uses scanf, which is broken-as-specified (for instance, it's allowed to crash the program if the input overflows the range of an int). Better code would be something like
char *linep = 0;
size_t asize = 0;
char *endp;
long c;
while (getline(&linep, &asize, stdin) > 0) {
errno = 0;
c = strtol(linep, &endp, 10);
if (linep == endp || *endp != '\0' || errno) {
puts("?Redo from start");
continue;
}
if (c == 0) break;
do_something_with(c);
}
free(linep);
Most likely the code is for reading in a list of integers, separated by a new line.
scanf will read in an integer, and put it into variable c.
The getchar is reading in the next character (assuming a new line)
Since it doesn't check, there is some potential that it wasn't a new line, or that scanf failed as the what it tried to read wasn't a number.
getchar(); is simply reading and consuming the character after the number, be it a space, comma, new line or the beginning of another integer or anything else.
IMO, this is not robust code. Good code would 1) at least test the result of scanf() and 2) test or limit the consumption of the following character to prevent "eating" a potential sign of the following number. Remember code cannot control what a user types, but has to cope with whatever is entered.
v space
"123 456"
v comma
"123,456"
v negative sign
"123-456"
how can I enforce following input restriction in c?
First line contains float ,
Second line contains float ,
Third line int,
after pressing enter three times in console, program should be able to read each line and put the contents in respective int,int,float variables.
After three enter key press program should not wait for user input and start validation.
some test cases
line1: 34
line2:4
line3:12
result: ok
line1:
line2:4
line3:12
result: not ok
line1: Hi
line2:4
line3:12
result: not ok
so far I used the basics
scanf("%f",&p);
scanf("%f",&r);
scanf("%d",&t);
it works fine for test case 1 and 3, but fails when I leave an empty line.
You should always check the return value of scanf.
The reason is that the return value is what scanf uses to communicate conversion errors, among other errors. For example, if your program tells scanf to expect a sequence of decimal digits, and scanf encounters something that doesn't match that pattern, the return value will indicate this failure.
The value returned will be the number of items that are successfully assigned to. For example,
char str[128];
int x, y = scanf("%d %127s", &x, str);
If y is 1, then it should be assumed that x is safe to use. If y is 2, then it should be assumed that both x and str are safe to use.
This answers part of your question. The next part is how you can go about ensuring that the input is in the form of lines. scanf doesn't strictly deal with lines; it deals with other units, such as %d being an int encoded as a sequence of decimal digits (and a sign); it'll return once the decimal digit sequence ends... There's no guarantee that the decimal digits will occupy the entirety of the line.
There are actually two problems here: leading and trailing whitespace. All format specifiers, with the exception of [, c, C, and n, will cause leading whitespace to be discarded. If you want to handle leading whitespace differently, you'll need to codify how you expect leading whitespace to be handled.
Consider that discarding user input is almost always (if not always) a bad idea. If you don't care what the remainder of the line contains, you could use something like scanf("%*[^\n]"); getchar(); to discard everything trailing up to and including the '\n' newline character... The first statement would attempt to read as many non-newline characters as possible, and the second would discard the terminating newline character. However, if you want to ensure that the input occupies the entirety of the line, then you need to test the value returned by getchar.
An example using all of these considerations:
/* Test for leading whitespace (including newlines) */
int c = getchar();
if (c != '-' && !isdigit(c)) {
/* Leading whitespace found */
}
ungetc(c);
/* Test for correct data conversion */
int x, y = scanf("%d", &x);
if (y != 1) {
/* Something non-numeric was entered */
}
/* Test for trailing newline */
c = getchar();
if (c != '\n') {
/* Trailing newline found */
}
Armed with this information, perhaps you can come up with an attempt and update your question with some code if you have any problems...
P.S. I noticed in the code you wrote, you seem to have %f and %d confused; %f is for reading into floats, and %d is for reading into ints, not the other way around...
As soon as I read line wise input, I know that fgets + sscanf must be used instead of direct scanf. Of course you can use getc/getchar as a workaround, but you can get corner cases, where I findfgets + sscanf cleaner. Example to get a float alone on a line:
char line[80], dummy[2];
float val;
if (fgets(line, sizeof(line), stdin) == NULL)...
if (sscanf(line, "%f%1s", &val, dummy) != 1)...
// Ok val was alone on the line with optional ignored blanks before and/or after
You could also add a test for loooong lines :
if ((line[0] != 0) && (line[strlen(line)-1 != '\n'))...
In a program I'm writing, there is a call to scanf(), which reads a long decimal number storing money.
do {
fflush(stdin);
printf("What is the number?\n");
} while (scanf("%Lf", &n.amt) == 0);
However, when debugging, I see n.amt is equal to 0. If I entered 100, why is it showing that it read a zero? At first, I was using a float, I changed that to a long double, but this problem persists.
This is also evident, because this data is later written to a file, and 0 is also written to there.
When getting input for a numeric, it is a bit tricky to protect against both an empty string ([enter]) or garbage input without causing your input to hang on a blank line when using scanf. The following reads the value as a string and protects against no input and garbage input without a hang. It will only proceed if there is a valid conversion to a double value with strtod (you can substitute strtold for long double):
#include <stdio.h>
#include <stdlib.h>
int main () {
char amount[50] = {0};
char *ep = NULL;
double n_amt = 0.0;
do {
/* protect against [enter] and garbage as input */
while (printf ("\nEnter the amount of money in the transaction: $ ") &&
scanf ("%49[^\n]%*c", amount) == 0 && getchar()) ;
/* convert to double */
n_amt = strtod (amount, &ep);
/* loop if no valid conversion */
} while ( &amount[0] == ep );
printf ("\n n.amt = %lf\n\n", n_amt);
return 0;
}
output:
$ ./bin/scanf_double
Enter the amount of money in the transaction: $
Enter the amount of money in the transaction: $ lsdkfj
Enter the amount of money in the transaction: $ 123.45
n.amt = 123.450000
Note: you are better off handling money as integer values rather than floating point. You are also better off using fgets or getline to read amount rather than scanf, but the purpose of the example was to provide a scanf solution.
equivalent input using fgets
do {
printf ("\nEnter the amount of money in the transaction: $ ");
fgets (amount, MAXL, stdin);
n_amt = strtod (amount, &ep);
} while ( &amount[0] == ep );
There are several problems with the code.
First, as already been noted, fflush(stdin) is undefined behavior. Although its behavior for input stream might be documented for a particular implementation (with glibc, fflush(stdin) flushes unread input), this is not portable behavior.
Removing fflush() won't be enough. If scanf() gets a format specification like '%lF', and after skipping any whitespace in the input stream the next character will not be convertible to the requested format specification (it's not a digit, a decimal point, or +/- sign for the '%lF' format specification, for example) the next character actually remains unread, and if there are no other format specifications that have been successfully converted, scanf() would return 0. If you loop around again, the unread character will still not be convertible, so you end up with an infinite loop.
I never liked using scanf(), because handling this kind of an error condition was always awkward.
I prefer to use fgets(), to read the entire line of input into a buffer, and, if you insist, use sscanf() to parse it. With that approach, the error recovery semantics will be easy to implement.