gregory@ritcsh.UUCP (Gregory Conway) (05/17/88)
An interesting point came to mind as I was working today. I thought I might
share it with those of you who are (or know someone who is) learning the
C language. It seems to me that a great deal of confusion could be saved
when learning printf, scanf, fprintf, fscanf, sprintf, and sscanf. The
point is really simple, don't use printf and scanf. Use, instead,
fprintf (stdout, "....") and fscanf (stdin, "....", &whatever). Why, you
ask?? Well, if you think about it, scanf and printf are really special
cases of fscanf and fprintf. The mental correlation is easier if you remember
you always operate on an IO path, represented by some file. (stdin and stdout
are just standard file, right? - hence Fscanf and Fprintf) Then, when the
user wants to use sprintf and sscanf, he or she need only remember the the
"IO path" is a stream, a buffer is you will. After a person has a complete
understanding of how all this fits together, he or she could easily use the
shorter, easier scanf and printf. Does anyone else think this seems like a
good way to learn the rudiments of IO in C?? Flames are welcome. ;-)
--
================================================================================
Gregory Conway@Computer Science House UUCP: ...rochester!ritcv!ritcsh!gregory
Rochester Institute of Technology, Rochester, NY
"I got an allergy to Perrier, daylight, and responsibility", Marillionpjh@mccc.UUCP (Pete Holsberg) (05/18/88)
In article <2454@ritcsh.UUCP> gregory@ritcsh.UUCP (Gregory Conway) writes:
...An interesting point came to mind as I was working today. I thought I might
...share it with those of you who are (or know someone who is) learning the
...C language. It seems to me that a great deal of confusion could be saved
...when learning printf, scanf, fprintf, fscanf, sprintf, and sscanf. The
...point is really simple, don't use printf and scanf. Use, instead,
...fprintf (stdout, "....") and fscanf (stdin, "....", &whatever). Why, you
...ask?? Well, if you think about it, scanf and printf are really special
...cases of fscanf and fprintf. The mental correlation is easier if you remember
...you always operate on an IO path, represented by some file. (stdin and stdout
...are just standard file, right? - hence Fscanf and Fprintf) Then, when the
...user wants to use sprintf and sscanf, he or she need only remember the the
..."IO path" is a stream, a buffer is you will. After a person has a complete
...understanding of how all this fits together, he or she could easily use the
...shorter, easier scanf and printf. Does anyone else think this seems like a
...good way to learn the rudiments of IO in C?? Flames are welcome. ;-)
But that adds an incredible burden to the beginner -- thinking about
streams and the additional xprintf/scanf stuff in addition to getting
used to the notation of C. No flame here, but I do think it's a bad
idea. At the end of the course, of course, one admits that
printf()/scanf() are special cases of fprintf()/fscanf() -- of course! :-)jesse@proxftl.UUCP (Jesse Perry) (05/20/88)
In article <2454@ritcsh.UUCP>, gregory@ritcsh.UUCP (Gregory Conway) writes: >The >point is really simple, don't use printf and scanf. Use, instead, >fprintf (stdout, "....") and fscanf (stdin, "....", &whatever). Please, PLEASE don't tell people to use either scanf() or fscanf(). Instead use gets() or fgets(), followed by sscanf(). Code which uses scanf() or fscanf() is susceptible to a nasty problem if the input stream is not correctly formatted. The problem is that these functions do not stop reading input at end of line. They only stop when each % item in the control string has been matched (or EOF is found). If the user fails to enter all the fields expected by the control string, the (f)scanf() function will assume that the missing data is on the following line(s). If this happens with scanf(), the program appears to hang -- it is waiting for the user to enter that next line, but the user won't because he is waiting for the results of the line he just entered (unaware that the entered line is incomplete). If the input stream for fscanf() is incorrect, the program will not (typically) hang, but it will mung the input lines together in crazy ways, and not report any error. Using (f)gets() followed by sscanf() is much more reliable, since format errors can be detected and reported immediately. >Gregory Conway@Computer Science House UUCP: ...rochester!ritcv!ritcsh!gregory >Rochester Institute of Technology, Rochester, NY Jesse Perry (RIT '87 :-) UUCP: uunet!proxftl!jesse BITNET: allegra!novavax!proxftl@psuvax1.uucp ARPA: sunvice!proxftl!jesse@sun.com
karl@haddock.ISC.COM (Karl Heuer) (05/24/88)
In article <200@proxftl.UUCP> jesse@proxftl.UUCP (Jesse Perry) implores people not to use scanf(). To avoid misunderstandings, I would rephrase it thus: The scanf() family is for *free-format* input -- non-significant whitespace, including newline, tends to be ignored. If you need line-oriented (e.g. prompted) input, you probably want to use something else. >Using (f)gets() followed by sscanf() is much more reliable, since format >errors can be detected and reported immediately. Let me add that fgets() is better than gets() in that it does bounds-checking (but even so, programs seldom do anything reasonable when it is detected). Also, when using fgets/sscanf it's easy to overlook the error of having *too much* data on one input line -- one way to catch this is to put " %c" at the end of the format (and an appropriate dummy variable in the arglist), and expect the return value to be one *less* than the number of variables passed. Karl W. Z. Heuer (ima!haddock!karl or karl@haddock.isc.com), The Walking Lint