Many people said that scanf
shouldn\'t be used in \"more serious program\", same as with getline
.
I started to be lost: if every input fun
There are several problems with using scanf
:
reading text with a plain %s
conversion specifier has the same risk as using gets()
; if the user types in a string that's longer than what the target buffer is sized to hold, you'll get a buffer overrun;
if using %d
or %f
to read numeric input, certain bad patterns cannot be caught and rejected completely -- if you're reading an integer with %d
and the user types "12r4
", scanf
will convert and assign the 12
while leaving r4
in the input stream to foul up the next read;
some conversion specifiers skip leading whitespace, others do not, and failure to take that into account can lead to problems where some input is skipped completely;
Basically, it takes a lot of extra effort to bulletproof reads using scanf
.
A good alternative is to read all input as text using fgets()
, and then tokenize and convert the input using sscanf
or combinations of strtok
, strtol
, strtod
, etc.
Generally, fgets()
is considered a good option. It reads whole lines into a buffer, and from there you can do what you need. If you want behavior like scanf()
, you can pass the strings you read along to sscanf()
.
The main advantage of this, is that if the string fails to convert, it's easy to recover, whereas with scanf()
you're left with input on stdin
which you need to drain. Plus, you won't wind up in the pitfall of mixing line-oriented input with scanf()
, which causes headaches when things like \n
get left on stdin
commonly leading new coders to believe the input calls had been ignored altogether.
Something like this might be to your liking:
char line[256];
int i;
if (fgets(line, sizeof(line), stdin)) {
if (1 == sscanf(line, "%d", &i)) {
/* i can be safely used */
}
}
Above you should note that fgets()
returns NULL
on EOF or error, which is why I wrapped it in an if
. The sscanf()
call returns the number of fields that were successfully converted.
Keep in mind that fgets()
may not read a whole line if the line is larger than your buffer, which in a "serious" program is certainly something you should consider.
For simple input where you can set a fixed limit on the input length, I would recommend reading the data from the terminal with fgets()
.
This is because fgets()
lets you specify the buffer size (as opposed to gets()
, which for this very reason should pretty much never be used to read input from humans):
char line[256];
if(fgets(line, sizeof line, stdin) != NULL)
{
/* Now inspect and further parse the string in line. */
}
Remember that it will retain e.g. the linefeed character(s), which might be surprising.
UPDATE: As pointed out in a comment, there's a better alternative if you're okay with getting responsibility for tracking the memory: getline()
. This is probably the best general-purpose solution for POSIX code, since it doesn't have any static limit on the length of lines to be read.
Use fgets
to get the data and use sscanf
(or another method) to interpret them.
See this page to learn why it is better to use fgets
+ sscanf
rather than scanf
http://c-faq.com/stdio/scanfprobs.html