UNIVERSITY OF CALIFORNIA, SANTA CRUZ BOARD OF STUDIES IN COMPUTER ENGINEERING CMPE-13/L: COMPUTER SYSTEMS AND C PROGRAMMING SPRING 2012

Transcription

1 UNIVERSITY OF CALIFORNIA, SANTA CRUZ BOARD OF STUDIES IN COMPUTER ENGINEERING CMPE-13/L: COMPUTER SYSTEMS AND C PROGRAMMING SPRING 2012 NOTES TO ACCOMPANY THE C PROGRAMMING LANGUAGE, BY KERNIGHAN AND RITCHIE ( K&R ) Chapter 7: Input and Output BY STEVE SUMMIT Page 151: By Input and output facilities are not part of the C language itself, we mean that things like printf are just function calls like any other. C has no built-in input or output statements. For our purposes, the implications of this fact--that I/O is not built in--is mainly that the compiler may not do as much checking as we might like it to. If we accidentally write double d = 1.23; printf("%d\n", d); the compiler says, Hmm, a function named printf is being called with a string and a double. Okay by me. The compiler does not (and, in general, could not even if it wanted to) notice that the %d format requires an int. Although the title of this chapter is Input and Output, it appears that we ll also be meeting a few other routines from the standard library. If you start to do any serious programming on a particular system, you ll undoubtedly discover that it has a number of more specialized input/output (and other system-related) routines available, which promise better performance or nicer functionality than the pedestrian routines of C s standard library. You should resist the temptation to use these nonstandard routines. Because the standard library routines are defined precisely and exist in compatible form on any system where C exists, there are some real advantages to using them. (On the other hand, when you need to do something which C s standard library routines don t provide, you ll generally turn to your machine s system-specific routines right away, as they may be your only choice. One common example is when you d like to read one character immediately, without waiting for the RETURN key. How you do that depends on what system you re using; it is not defined by C.) Section 7.1: Standard Input and Output Note that a text stream might refer to input (to the program) from the keyboard or output to the screen, or input and output from files on disk. (For that matter, it can also refer to input and output from other peripheral devices, or the network.) Note that the stdio library generally does newline translation for you. If you know that lines are terminated by a linefeed on Unix and a carriage return on the Macintosh and a carriage-return/linefeed combination on MS-DOS, you don t have to worry about these things in C, because the line termination will always appear to a C program to be a single \n. (That is, when reading, a single \n represents the

2 end of the line being read, and when writing, writing a \n causes the underlying system s actual end-ofline representation to be written.) Pages : The lower program is an example of a filter: it reads its standard input, filters (that is, processes) it in some way, and writes the result to its standard output. Filters are designed for (and are only really useful under) a command-line interface such as the Unix shells or the MS-DOS command.com interface. Obviously, you would rarely invoke a program like lower by itself, because you would have to type the input text at it and you could only see the output ephemerally on your screen. To do any real work, you would always redirect the input: lower < inputfile and perhaps the output: lower < inputfile > outputfile (notice that spaces may precede and follow the < and > characters). Or, a filter program like lower might appear in a longer pipeline: or oneprogram lower anotherprogram anotherprogram < inputfile lower thirdprogram > outputfile Filters like these are not terribly useful, though, under a Graphical User Interface such as the Macintosh or Microsoft Windows. Section 7.2: Formatted Output -- Printf Pages : To summarize the important points of this section: printf s output goes to the standard output, just like putchar. Everything in printf s format string is either a plain character to be printed as-is, or a %- specifier which generally causes one argument to be consumed, formatted, and printed. (Occasionally, a single %-specifier consumes two or three arguments if the width or precision is *, or zero arguments if the specifier is %%.) There s a fairly long list of conversion specifiers; see the table on page 154. Always be careful that the conversions you request (in the format string) match the arguments you supply. You can print to a string (instead of the standard output) with sprintf. (This is the usual way of converting numbers to strings in C; the itoa function we were playing with in section 3.6 on page 64 is nonstandard, and unnecessary.) Section 7.3: Variable-length Argument Lists

3 This is an advanced section which you don t need to read. Section 7.4: Formatted Input -- Scanf Page 157: Somehow we ve managed to make it through six chapters without meeting scanf, which it turns out is just as well. In the examples in this book so far, all input (from the user, or otherwise) has been done with getchar or getline. If we needed to input a number, we did things like char line[maxline]; int number; getline(line, MAXLINE); number = atoi(line); Using scanf, we could simplify this to int number; scanf("%d", &number); This simplification is convenient and superficially attractive, and it works, as far as it goes. The problem is that scanf does not work well in more complicated situations. In section 7.1, we said that calls to putchar and printf could be interleaved. The same is not always true of scanf: you can have baffling problems if you try to intermix calls to scanf with calls to getchar or getline. Worse, it turns out that scanf s error handling is inadequate for many purposes. It tells you whether a conversion succeeded or not (more precisely, it tells you how many conversions succeeded), but it doesn t tell you anything more than that (unless you ask very carefully). Like atoi and atof, scanf stops reading characters when it s processing a %d or %f input and it finds a non-numeric character. Suppose you ve prompted the user to enter a number, and the user accidentally types the letter `x. scanf might return 0, indicating that it couldn t convert a number, but the unconvertable text (the `x ) remains on the input stream unless you figure out some other way to remove it. For these reasons (and several others, which I won t bother to mention) it s generally recommended that scanf not be used for unstructured input such as user prompts. It s much better to read entire lines with something like getline (as we ve been doing all along) and then process the line somehow. If the line is supposed to be a single number, you can use atoi or atof to convert it. If the line has more complicated structure, you can use sscanf (which we ll meet in a minute) to parse it. (It s better to use sscanf than scanf because when sscanf fails, you have complete control over what you do next. When scanf fails, on the other hand, you re at the mercy of where in the input stream it has left you.) With that little diatribe against scanf out of the way, here are a few comments on individual points made in section 7.4. We ve met a few functions (e.g. getline, month_day in section 5.7 on page 111) which return more than one value; the way they do so is to accept a pointer argument that tells them where (in the caller) to write the returned value. scanf is the epitome of such functions: it returns potentially many values (one for each %-specifier in its format string), and for each value converted and returned, it needs a pointer argument.

4 The statement on page 157 that blanks or tabs in the format string are ignored (which is repeated on page 159) is a simplification: in actuality, a blank or tab (or newline; actually any whitespace) in the format string causes scanf to skip whitespace (blanks, tabs, etc.) in the input stream. A * character in a scanf conversion specifier means something completely different than it does for printf: for scanf, it means to suppress assignment (i.e. for that conversion specifier, there isn t a pointer in the argument list to receive the converted value, so the converted value is discarded). With scanf, there is no direct way of taking a field width from the argument list, as * does for printf. Conversion specifiers like %d and %f automatically skip leading whitespace while looking for something to convert. This means that the format strings "%d %d" and "%d%d" act exactly the same-- the whitespace in the first format string causes whitespace to be skipped before the second %d, but the second %d would have skipped that whitespace anyway. (Yet another scanf foible is that the innocuouslooking format string "%d\n" converts a number and then skips whitespace, which means that it will gobble up not only a newline following the number it converts, but any number of newlines or whitespace, and in fact it will keep reading until it finds a non-whitespace character, which it then won t read. This sounds confusing, but so is scanf s behavior when given a format string like "%d\n". The moral is simple: don t use trailing \n s in scanf format strings.) Page 158: Notice that, for scanf, the %e, %f, and %g formats are all the same, and signify conversion of a float value (they accept a pointer argument of type float *). To convert a double, you need to use %le, %lf, or %lg. (This is quite different from the printf family, which uses %e, %f, and %g for floats and doubles, though all three request different formats. Furthermore, %le, %lf, and %lg are technically incorrect for printf, though most compilers probably accept them.) Page 159: More precisely, the reason that you don t need to use a & with monthname is that an array, when it appears in an expression like this, is automatically converted to a pointer. The dual-format date conversion example in the middle of page 159 is a nice example of the advantages of calling getline and then sscanf. At the beginning of this section, I said that when sscanf fails, you have complete control over what you do next. Here, what you do next is try calling sscanf again, on the very same input string (thus effectively backing up to the very beginning of it), using a different format string, to try parsing the input a different way. Section 7.5: File Access Page 160: We ve come an amazingly long way without ever having to open a file (we ve been relying exclusively on those predefined standard input and output streams) but now it s time to take the plunge. The concept of a file pointer is an important one. It would theoretically be possible to mention the name of a file each time it was desired to read from or write to it. But such an approach would have a number of drawbacks. Instead, the usual approach (and the one taken in C s stdio library) is that you mention the name of the file once, at the time you open it. Thereafter, you use some little token--in this case, the file pointer--which keeps track (both for your sake and the library s) of which file you re talking about. Whenever you want to read from or write to one of the files you re working with, you identify

5 that file by using the file pointer you obtained from fopen when you opened the file. (It is possible to have several files open, as long as you use distinct variables to store the file pointers.) Not only do you not need to know the details of a FILE structure, you don t even need to know what the buffer is that the structure contains the location of. In general, the only declaration you need for a file pointer is the declaration of the file pointer: FILE *fp; You should never need to type the line FILE *fopen(char *name, char *mode); because it s provided for you in <stdio.h>. If you skipped section 6.7, you don t know about typedef, but don t worry. Just assume that FILE is a type, like int, except one that is defined by <stdio.h> instead of being built into the language. Furthermore, note that you will never be using variables of type FILE; you will always be using pointers to this type, or FILE *. A binary file is one which is treated as an arbitrary series of byte values, as opposed to a text file. We won t be working with binary files, but if you ever do, remember to use fopen modes like "rb" and "wb" when opening them. Page 161: We won t worry too much about error handling for now, but if you start writing production programs, it s something you ll want to learn about. It s extremely annoying for a program to say can t open file without saying why. (Some particularly unhelpful programs don t even tell you which file they couldn t open.) On this page we learn about four new functions, getc, putc, fprintf, and fscanf, which are just like functions that we ve already been using except that they let you specify a file pointer to tell them which file (or other I/O stream) to read from or write to. (Note that for putc, the extra FILE * argument comes last, while for fprintf and fscanf, it comes first.) Page 162: cat is about the most basic and important file-handling program there is (even if its name is a bit obscure). The cat program on page 162 is a bit like the hello, world program on page 6--it may seem trivial, but if you can get it to work, you re over the biggest first hurdle when it comes to handling files at all. Compare the cat program (and especially its filecopy function) to the file copying program on page 16 of section cat is essentially the same program, except that it accepts filenames on the command line. Since the authors advise calling fclose in part to flush the buffer in which putc is collecting output, you may wonder why the program at the top of the page does not call fclose on its output stream. The reason can be found in the next sentence: an implicit fclose happens automatically for any streams which remain open when the program exits normally.

6 In general, it s a good idea to close any streams you open, but not to close the preopened streams such as stdin and stdout. (Since the system opened them for you as your program was starting up, it s appropriate to let it close them for you as your program exits.) Section 7.6: Error Handling -- Stderr and Exit Page 163: stdout and stderr are both predefined output streams; for our purposes, the only difference between them is that stderr is not likely to be redirected by the user, so the error messages printed to stderr will always appear on the screen, where they can be seen. Page 164: The cryptic note about a pattern-matching program simply means that if you want to search the source code of a program for all the exit status values it can return, exit might be an easier string to search for than return. (Every call to exit represents an exit from the program, but not every return statement does.) The feof and ferror functions can be used to check for error conditions more carefully. In general, input routines (such as getchar and getline) return some special value to tell you that they couldn t read any more. Often, this value is EOF, reinforcing the notion that the only possible reason they couldn t read any more was because end-of-file had been reached. However, it s also possible that there was a read error, and you can call feof or ferror to determine whether this was the case. On the output side, though the output routines generally do return an error indication, few programs bother to check the return values from every call to functions such as putchar and printf. One way to check for output errors, without having to check the return value of every function, is to call ferror on the output stream (which might be stdout) at key points. Section 7.7: Line Input and Output Pages : To summarize, puts is like fputs except that the stream is assumed to be the standard output (stdout), and a newline ( \n ) is automatically appended. gets is like fgets except that the stream is assumed to be stdin, and the newline ( \n ) is deleted, and there s no way to specify the maximum line length. This last fact means that you almost never want to use gets at all: since you can t tell it how big the array it s to read into is, there s no way to guarantee that some unexpectedly-long input line won t overflow the array, with dire results. (When discussing the drawbacks of gets, it s customary to point out that the Internet worm, a program that wreaked havoc in 1988 by breaking into computers all over the net, was able to do so in part because a key network utility on many Unix systems used gets, and the worm was able to overflow the buffer in a particularly low, cunning way, with the dire result that the worm achieved superuser access to the attacked machine.) Section 7.8.1: String Operations Page 166: One thing to beware of is that strcpy s arguments--more precisely, the strings pointed to by its arguments--must not overlap. Another string function we ve seen is strstr: strstr(s,t) return pointer to first t in s, or NULL if not present

7 Section 7.8.2: Character Class Testing and Conversion One quirk of these functions, which the authors mention briefly, is that although they accept arguments of type int, it is not legal to pass just any int value to them. If you were to attempt to call isupper(12345), it might do something bizarre. You should only call these functions with arguments which represent valid character values. (Also, they are guaranteed to accept the value EOF gracefully.) Section 7.8.3: Ungetc There s not much more to say about ungetc, but two more stdio functions which might deserve mention are fread and fwrite. getc and putc (and getchar and putchar) allow you to read and write a character at a time, while fgets and fputs read and write a line at a time. The printf family of routines does formatted output, and the scanf family does formatted input. But what if you want to read or write a big block of unformatted characters, not necessarily one line long? You could use getc or putc in a loop, but another solution is to use the fread and fwrite functions, which are (briefly) described in appendix B1.5 on page 247. Section 7.8.4: Command Execution Page 167: The only thing to add to this brief description of system concerns the disposition of the executed command s output. (Similar arguments apply to its input.) The output generally goes wherever the calling program s output goes, though if the calling program has done anything with stdout (such as closing it, or redirecting it within the program with freopen), those changes will probably not affect the output of system. One way to achieve redirection of the command executed by system, if the operating system permits it, is to use redirection notation within the command line passed to system: system("date > outfile"); Note also that the exit status returned by the program (and hence perhaps by system) does not necessarily have anything to do with anything printed by the program. One way to capture the output printed by the program is to use redirection, as above, then open and read the output file. Section 7.8.5: Storage Management The important thing to know about malloc and free and friends is to be careful when calling them. It is easy to abuse them, either by using more space than you ask for (that is, writing beyond the ends of an allocated block) or by continuing to use a pointer after the memory it points to has been freed (perhaps because you had several pointers to the same block of memory, and you forgot that when you freed one pointer they all became invalid). malloc-related bugs can be difficult and frustrating to track down, so it s good to use programming practices which help to assure that the bugs don t happen in the first place. (One such practice is to make sure that pointer variables are set to NULL when they don t point anywhere, and to occasionally check pointer values--for instance at entry to an important pointerusing function--to make sure that they re not NULL.) As we mentioned on page 142 in section 6.5, it is no longer necessary (that is, in ANSI C) to cast malloc s value to the appropriate type, though it doesn t hurt to do so.

8 Section 7.8.6: Mathematical Functions Page 168: Note that the pow function is how you do exponentiation in C--C does not have a built-in exponentiation operator (such as ** or ^ in some other languages). Before calling these functions, remember to #include <math.h>. (It s always a good idea to #include the appropriate header(s) before using any library functions, but the math functions are particularly unlikely to work correctly if you forget.) Also, under Unix, you may have to explicitly request the math library by adding the -lm option at the end of the command line when compiling/linking. Section 7.8.7: Random Number Generation There is a typo in some printings; the code for returning a floating-point random number in the interval [0,1) should be #define frand() ((double) rand() / (RAND_MAX+1.0)) If you want to get random integers from M to N, you can use something like M + (int)(frand() * (N-M+1)) [Setting] the seed for rand refers to the fact that, by default, the sequence of pseudo-random numbers returned by rand is the same each time your program runs. To randomize it, you can call srand at the beginning of the program, handing it some truly random number, such as a value having to do with the time of day. (One way is with code like #include <stdlib.h> #include <time.h> srand((unsigned int)time((time_t *)NULL)); which uses the time function mentioned on page 256 in appendix B10.) One other caveat about rand: don t try to generate random 0/1 values (to simulate a coin flip, perhaps) with code like rand() % 2 This looks like it ought to work, but it turns out that on some systems rand isn t always perfectly random, and returns values which consistently alternate even, odd, even, odd, etc. (In fact, for similar reasons, you shouldn t usually use rand() % N for any value of N.) A good way to get random 0/1 values would be (int)(frand() * 2) based on the other frand() examples above.