Help with scanf

[Sivarn]

I'm writing a program for that takes dates as input using scanf. I
want to verify that the user is inputting a full 4 digits for the
year. How do I do this? I know that the return value on printf is the
number of printed characters; so if I could somehow get my year
variable to store the leading zeros, I could just run a check:

int dummy = 0;

dummy = printf("%d", year);

if (dummy != 4)
{
...do something...
}

 

[Leor Zolman]

I'm writing a program for that takes dates as input using scanf. I
want to verify that the user is inputting a full 4 digits for the
year. How do I do this? I know that the return value on printf is the
number of printed characters; so if I could somehow get my year
variable to store the leading zeros, I could just run a check:

int dummy = 0;

dummy = printf("%d", year);

if (dummy != 4)
{
...do something...
}

Wait a minute...you started by asking about scanf, and you say you want to
verify the input? Then I'm sure you'd rather not have to print the value
just in order to be able to validate the user input, right?

You certainly don't have to. Let's go ahead and use scanf, because that's
how you say you're doing it (but scanf is essentially useless if you need
serious validation of input. More on that later...):

int count;
int year;
count = scanf("%d", &year);

Note that you must provide the & on year, since scanf has to know /where/
to put the value. count tells you how many "items" were scanned; it could
be 0 if the user didn't type a number. So let's test that:

if (count != 1)
{
printf("Bad input. You lose.\n");
exit(1);
}

(Of course you might choose to do something other than exit here.)

So, how to test for 4 digits? Well, the easiest way I can think of is to
just test for a valid (or invalid) range:

if (year < 1900 || year > 2030) /* or whatever */
{
printf("Bad year. You're outa here.\n");
exit (1);
}

If you /really/ want "any 4 digit number", just test that it is between
1000 and 9999.

So that takes care of that. Now we can improve the input. sscanf is a royal
pain to work with, because if the user just keeps pressing enter, it'll
merrily echo blank lines till doomsday (it ignores leading whitespace,
including newlines). And if the user presses, say, a letter when scanf is
looking for a number, that letter persists on the input stream the /next/
time you try to read a number, further wreaking havoc.

Better to force a single line of input, and then process it. I like to use
fgets to read a line into a buffer, and then sscanf to do the conversion.
sscanf is a lot like scanf, but it reads input from a string buffer instead
of from the standard input. Putting all of that together with some
re-prompting logic, here's a program for you:

#include <stdio.h>

int main()
{
int year;
char buffer[100];

while (1)
{
printf("Please enter a year: ");
fgets(buffer, 100, stdin);
if (sscanf(buffer, "%d", &year) != 1)
printf("that wasn't a number! Try again....\n");
else if (year < 1900 || year > 2030)
printf("Bad year! Must be between 1900 and 2030."
" Try again...\n");
else
break;
}

printf("Success! your year is %d\n", year);

return 0;
}

That is something you can now expand to support as much processing on that
line of input as you please, without running into a slew of problems you'd
get from using just scanf.

Good luck,
-leor

 

[Leor Zolman]

So that takes care of that. Now we can improve the input. sscanf is a royal
pain to work with

That should have read: /scanf/ is a royal pain...oops.
-leor

 

[Simon Biber]

if (count != 1)
{
printf("Bad input. You lose.\n");
exit(1);
}

1 is not a portable exit code (termination status); it might have unexpected
effects. If you want to indicate failure, do so explicitly with the macro
EXIT_FAILURE. The only portable exit codes are 0, EXIT_SUCCESS and
EXIT_FAILURE. The value of EXIT_SUCCESS may or may not be zero, but has the
same effect.
exit(EXIT_FAILURE);
EXIT_FAILURE is defined in <stdlib.h> which you should already have included
for the exit function itself. It might expand to 1 or to any other value
other than zero.

Also, please don't post tabs to newsgroups. Indenting should be done with
spaces.

[...]

#include <stdio.h>

int main()
{
int year;
char buffer[100];

while (1)
{
printf("Please enter a year: ");

Here you need to flush the stdout buffer to ensure that the prompt is
displayed to the screen before you wait for user input.
fflush(stdout);

fgets(buffer, 100, stdin);

I'd avoid magic numbers and check for success/failure
if(fgets(buffer, sizeof buffer, stdin) == NULL)
{
printf("There was a problem reading your input.\n");
exit(EXIT_FAILURE);
}

At this point if the user has entered a number outside the range of int, the
behaviour of sscanf will be undefined. This is a good point to validate the
input before continuing.
if(strlen(buffer) != 5 || strspn(buffer, "0123456789\n") != 5)
{
printf("That wasn't a four digit number! Try again...\n");
}
else

 

[Simon Biber]

I forgot to add that my changes to the code below require
#include <stdlib.h> /* for exit and EXIT_FAILURE */

int main()
{
int year;
char buffer[100];

while (1)
{
printf("Please enter a year: ");

Here you need to flush the stdout buffer to ensure that the prompt is
displayed to the screen before you wait for user input.
fflush(stdout);

fgets(buffer, 100, stdin);

I'd avoid magic numbers and check for success/failure
if(fgets(buffer, sizeof buffer, stdin) == NULL)
{
printf("There was a problem reading your input.\n");
exit(EXIT_FAILURE);
}

At this point if the user has entered a number outside the range of int, the
behaviour of sscanf will be undefined. This is a good point to validate the
input before continuing.
if(strlen(buffer) != 5 || strspn(buffer, "0123456789\n") != 5)
{
printf("That wasn't a four digit number! Try again...\n");
}
else

if (sscanf(buffer, "%d", &year) != 1)
printf("that wasn't a number! Try again....\n");
else if (year < 1900 || year > 2030)
printf("Bad year! Must be between 1900 and 2030."
" Try again...\n");
else
break;
}

printf("Success! your year is %d\n", year);

return 0;
}

 

[Arthur J. O'Dwyer]

Let's go ahead and use scanf, because that's how you say you're
doing it (but scanf is essentially useless if you need
serious validation of input. More on that later...):

Now, just a minute there! I'll grant you that scanf is less than
completely useful for *complex* validation, but *serious* validation
can indeed be performed, if you're willing to put up with the syntax.
I like scanf.

#include <stdio.h>
#include <stdlib.h>
#include <ctype.h>

int main(void)
{
char buffer[5] = {0};
char *bp;
int k;
int year;

puts("Enter a 4-digit year now.");
if (1 != scanf(" %4[0123456789]", buffer)) {
puts("No digits entered!");
}
else {
year = strtol(buffer, &bp, 10);
if (bp != buffer+4) {
puts("Fewer than 4 digits entered!");
}
else {
printf("You entered the (valid) year %d.\n", year);
}
}

k = getchar();
if (!isspace(k)) {
puts("You left some input at the end of your line.");
}
ungetc(k, stdin);

return 0;
}

So, how to test for 4 digits? Well, the easiest way I can think of is to
just test for a valid (or invalid) range:

if (year < 1900 || year > 2030) /* or whatever */

Presumably the OP's problem was that he wanted *four digits of input*,
not merely a number in the range 1000-9999; i.e., counting leading
zeroes.

So that takes care of that. Now we can improve the input. sscanf is a royal
pain to work with, because if the user just keeps pressing enter, it'll
merrily echo blank lines till doomsday (it ignores leading whitespace,
including newlines). And if the user presses, say, a letter when scanf is
looking for a number, that letter persists on the input stream the /next/
time you try to read a number, further wreaking havoc.

OTOH, sometimes that's a nice behavior, not least because it's easy
to predict its behavior. As opposed to...

Better to force a single line of input, and then process it.

....fgets, which reads either up to the first newline, *or* until its
buffer runs out, whichever comes first. Not that it's impossible
to do good stuff with fgets; it's not. But scanf's behavior isn't
entirely illogical, either.

HTH,
-Arthur

 

[Leor Zolman]

1 is not a portable exit code (termination status); it might have unexpected
effects. If you want to indicate failure, do so explicitly with the macro
EXIT_FAILURE. The only portable exit codes are 0, EXIT_SUCCESS and
EXIT_FAILURE. The value of EXIT_SUCCESS may or may not be zero, but has the
same effect.
exit(EXIT_FAILURE);
EXIT_FAILURE is defined in <stdlib.h> which you should already have included
for the exit function itself. It might expand to 1 or to any other value
other than zero.

Sorry, old habits die hard ;-)

Also, please don't post tabs to newsgroups. Indenting should be done with
spaces.

Arghh. I forgot this time; but generally I've been pretty good. In fact,
I'd just come up with an Epsilon macro that with one keystroke a)
untabifies my edit buffer, b) copies it into the clipboard, and c)
re-tabifies. Now I just have to remember to /use/ it.

[...]

#include <stdio.h>

int main()
{
int year;
char buffer[100];

while (1)
{
printf("Please enter a year: ");

Here you need to flush the stdout buffer to ensure that the prompt is
displayed to the screen before you wait for user input.
fflush(stdout);

Is that actually required for stdout if you then pause to read from stdin?
Where'd I get the impression there was some sort of special case for
that...

I'd avoid magic numbers and check for success/failure
if(fgets(buffer, sizeof buffer, stdin) == NULL)
{
printf("There was a problem reading your input.\n");
exit(EXIT_FAILURE);
}

At this point if the user has entered a number outside the range of int, the
behaviour of sscanf will be undefined. This is a good point to validate the
input before continuing.
if(strlen(buffer) != 5 || strspn(buffer, "0123456789\n") != 5)
{
printf("That wasn't a four digit number! Try again...\n");
}
else

Thanks!
-leor

 

[Leor Zolman]

Now, just a minute there! I'll grant you that scanf is less than
completely useful for *complex* validation, but *serious* validation
can indeed be performed, if you're willing to put up with the syntax.
I like scanf.

I think the way it ignores leading newlines alone is enough to justify
dispensing with it for interactive use. Do you really want to have to
include text such as "If you press Enter first and nothing happens, don't
keep wailing on the Enter key! Try something /else/!" as part of your
prompt?

#include <stdio.h>
#include <stdlib.h>
#include <ctype.h>

int main(void)
{
char buffer[5] = {0};
char *bp;
int k;
int year;

puts("Enter a 4-digit year now.");
if (1 != scanf(" %4[0123456789]", buffer)) {
puts("No digits entered!");
}
else {
year = strtol(buffer, &bp, 10);
if (bp != buffer+4) {
puts("Fewer than 4 digits entered!");
}
else {
printf("You entered the (valid) year %d.\n", year);
}
}

k = getchar();
if (!isspace(k)) {
puts("You left some input at the end of your line.");
}
ungetc(k, stdin);

return 0;
}

So, how to test for 4 digits? Well, the easiest way I can think of is to
just test for a valid (or invalid) range:

if (year < 1900 || year > 2030) /* or whatever */

Presumably the OP's problem was that he wanted *four digits of input*,
not merely a number in the range 1000-9999; i.e., counting leading
zeroes.

I'm not sure that's what he really wanted; It looks like he only wanted the
leading zeros as part of his printf-related validation scheme for the
input. I don't know, but the fact he's putting the year into an int pretty
much excludes his possible use for those leading zeros...

OTOH, sometimes that's a nice behavior, not least because it's easy
to predict its behavior. As opposed to...


...fgets, which reads either up to the first newline, *or* until its
buffer runs out, whichever comes first. Not that it's impossible
to do good stuff with fgets; it's not. But scanf's behavior isn't
entirely illogical, either.

A sane user interface has always been /much/ easier to get working for me
using fgets/sscanf, but of course YMMV.

HTH,
-Arthur

I expected to get some critique of this from folks, and wasn't
disappointed. I still don't quite have all the "modern C" idioms down
(EXIT_FAILURE seems to come real hard, perhaps because I just balk at
having to type it out...), but I'm slowly getting there ;-)
-leor

 

[olaf]

Hello

If you want some string to be has leading zero's

use
printf("%04d",1); => "0001"
printf("%04d",10001); => "10001"
printf("%04.4d",10001); => "1000"
printf("%4d",1); => " 1"


for a complete set of pssiblelities look in a good C manual.

Greetings

 

[Simon Biber]

Is that actually required for stdout if you then pause to read
from stdin? Where'd I get the impression there was some sort
of special case for that...

Although many systems do implement a special case that they flush stdout's
buffer when you read from stdin, it is still required on some systems so
it's a good idea to include the fflush(stdout) when writing portable code.

 

[Leor Zolman]

Although many systems do implement a special case that they flush stdout's
buffer when you read from stdin, it is still required on some systems so
it's a good idea to include the fflush(stdout) when writing portable code.

Well, then, that's the last straw. I've been driven to actually create a
checklist, because there's no /way/ I'm going to remember to flush my
stdout before reading stdin unless I have that written down somehwere
(grumble...) ;-)
-leor

 

[Dan Pop]

I'm writing a program for that takes dates as input using scanf. I
want to verify that the user is inputting a full 4 digits for the
year. How do I do this?

Try engaging your brain. What is the smallest 4-digit number? 1000.
What is the largest 4-digit number? 9999. So, the test for 4-digit
numbers (with no preceding zeros) becomes:

if (year >= 1000 && year <= 9999) /* good input */ ;
else /* bad input */ ;

Now, if your number is supposed to be a year, you may want to restrict
the valid input range even further, using exactly the same technique.

Dan

 

[Mike Wahler]

Is that actually required for stdout if you then pause to read from stdin?

Yes, if you want to guarantee the output appears before
the input request.

Where'd I get the impression there was some sort of special case for
that...

Probably from C++, where cin/cout are 'tied', causing
the output to appear first automatically.

-Mike

 

[Mike Wahler]

code.

Well, then, that's the last straw. I've been driven to actually create a
checklist, because there's no /way/ I'm going to remember to flush my
stdout before reading stdin unless I have that written down somehwere
(grumble...) ;-)

Or you see your program behave 'wrongly', i.e. it waits
for input before a 'prompt' appears (I've actually had this
happen to me on some older DOS platforms -- my lesson
was a 'real-world' one, so it stuck. ).

-Mike

 

[Jeremy Yallop]

Although many systems do implement a special case that they flush stdout's
buffer when you read from stdin, it is still required on some systems so
it's a good idea to include the fflush(stdout) when writing portable code.

Which systems require the flush?

Jeremy.

 

[Mike Wahler]

code.

Which systems require the flush?

It's not required by 'systems', but by the language
standard.

-Mike

 

[Jeremy Yallop]

It's not required by 'systems', but by the language
standard.

No. The intent of the standard is exactly the opposite.

5.1.2.3
The input and output dynamics of interactive devices shall take
place as specified in 7.19.3. The intent of these requirements is
that unbuffered or line-buffered output appear as soon as possible,
to ensure that prompting messages actually appear prior to a
program waiting for input.

7.19.3
Furthermore, characters are intended to be transmitted as a block
to the host environment when a buffer is filled, when input is
requested on an unbuffered stream, or when input is requested on a
line buffered stream that requires the transmission of characters
from the host environment.

This comes up rather often: see Chris Torek's article
<from a few days ago for an
example.

Also, your news client is munging quoted text. Could you fix it,
please?

Jeremy.

 

[Arthur J. O'Dwyer]

I think the way it ignores leading newlines alone is enough to justify
dispensing with it for interactive use. Do you really want to have to
include text such as "If you press Enter first and nothing happens, don't
keep wailing on the Enter key! Try something /else/!" as part of your
prompt?

That's not intrinsic behavior of 'scanf' in general, but of the '%d'
and other format specifiers. The only reason my code ignores leading
whitespace (including '\n') is because I told it to. If you want to
get rid of the leading-whitespace-gobbler, you just remove the whitespace-
gobbling format specifier from the format string. That is, change

if (1 != scanf(" %4[0123456789]", buffer)) {

to

if (1 != scanf("%4[0123456789]", buffer)) {

or if you're really stubborn and clever,

scanf("%*[\t ]");
if (1 != scanf("%4[0123456789]", buffer)) {

This *must* be two separate 'scanf' invocations, though; if you run the
format specifiers together, it *demands* leading whitespace, which is
certainly not what we want!

-Arthur

 

[Leor Zolman]

I think the way it ignores leading newlines alone is enough to justify
dispensing with it for interactive use. Do you really want to have to
include text such as "If you press Enter first and nothing happens, don't
keep wailing on the Enter key! Try something /else/!" as part of your
prompt?

That's not intrinsic behavior of 'scanf' in general, but of the '%d'
and other format specifiers. The only reason my code ignores leading
whitespace (including '\n') is because I told it to. If you want to
get rid of the leading-whitespace-gobbler, you just remove the whitespace-
gobbling format specifier from the format string. That is, change

if (1 != scanf(" %4[0123456789]", buffer)) {

to

if (1 != scanf("%4[0123456789]", buffer)) {

Ha! I must admit I had to stare at that new version for about 30 seconds
before I noticed the difference. I honestly didn't know you could do that
with scanf (If my own implementation of scanf from BDS C did that right, I
don't remember ever consciously thinking about it). So that's good to
know, and one point back to scanf's corner.
Thanks,
-leor

 

[Dan Pop]

don't remember ever consciously thinking about it). So that's good to
know, and one point back to scanf's corner.

In competent hands, scanf is a very powerful beast. Could have been even
better if the committee tried harder (the * feature of printf conversion
specifications is sometimes badly needed).

Dan