The documentation for f/s/scanf clearly indicates that they return the number of items sucessfully read AND ASSIGNED, or, under certain conditions, EOF. That is why I recommend to novices that they read the documentation for functions that they use. Having programmed life-support equipment, I am fully aware of the actual criminal liability one may subject oneself to by indulging in sloppy coding practices, regardless of whether it is due to negligence or ignorance.
The use of "rewind (stdin)" is more problematic. I use it to clear the input buffer so that the "getchar ()" won't terminate because of things left in the buffer by scanf (a very common occurrence). Some people use "fflush (stdin)", and it works on some compilers, but "fflush" is distinctly specified to work on output buffers, not input buffers.
"rewind (stdin)" is a synonym for "fseek(stdin, 0L, SEEK_SET)". "fseek" is, of course, defined to work for both input and output files. There is a valid question about whether or not one can rewind a terminal (go back in the past? nahhhh). Most systems will rewind stdin by clearing the buffer. Others will generate an error. I would never use it in production code. It is there simply to make the getchar () work under the conditions stated above. The use of the getchar () is subject to question. It is simply there to keep the window open so that the user can see the results of the app. It is a characteristic of programs that they are SUPPOSED to terminate when they're done. The schlocky use of getchar () is just a way to make "done" contingent upon user input, in case the app was started by a tool (compiler/linker) or by double-clicking an icon. The sure way to keep the window open is to start the app from the command line. The window thus belongs to "cmd", not the app, and will still be there when the app terminates.
C does not provide a reliable way to clear the input stream associated with stdin. C++ does. Unless you dink with stdin, it is a buffered stream. It does no good to programmatically dink with the put and get pointers for the stream because the buffer is filled by issuing a raw "read ()". There is nothing in the buffer to use or clear until the read terminates. This is conditioned on the detection of a newline. You can't know to dink with the pointers until a condition has been met that means you don't HAVE to dink with the pointers.
Input between the standard stream (stdin) and the actual input device is obviously implementation specific. After all, the system may have a 10-key pad or some keyboard other than the type usually associated with a specific implementation such as the typical desktop PC. This means that for reliable performance, you deal with the implementation (in other words, portability goes out the window). This is not, de facto, a Bad Thang. No one expects code generated on their PC to be able to port directly to their automobile and control the fuel/air mixture. Portability has to be addressed sensibly.
If one wants to absolutely and correctly deal with the keyboard in Windows, one uses the Windows Console API, which is a couple of implementation layers between standard C and the machine. For *nix, one would use implementation-specific features associated with unistd.h, termio.h, stuff of that ilk. For a mail sorter for the USPS, an intravenous infusion pump, or a Polaroid film battery tester/sorter, one would use something else entirely different for each case.
For trivial examples, I use "rewind (stdin)", which has no effects regarding clearing the screen, incidentally. It may not work for every viewer of the thread. If not, ask, and a suitable other solution can be pursued.