If you persist with scanf, then get used to all sorts of funnies.
Rule 1 - scanf leaves input.
So if you type in
1234ABCD<return>
and you try and read with %d, then you will have ABCD<return> to deal with at some later stage. Unless you're careful, even minor user typos will mess with your head.
Rule 2 - scanf skips leading white space, and stops at trailing white space.
For everything except %c conversions.
Rule 3 - if the conversion doesn't happen, then the data is still there.
Type in
ABCD<return>
and you try and read with %d, then you will have ABCD<return> to deal with.
Recovering from user input errors is a PITA, made even worse by the fact that few people even bother to look at what scanf() returns.
Keeping track of exactly where you are is hard work, even when the user is playing by the rules.
Oh, and ignore anyone who suggests using fflush(stdin) as a solution to the woes of dealing with input that scanf() doesn't deal with.
> If my book wants me to continue using scanf
Skip ahead, and find out how much longer you have to wait before you get to fgets()
