These are errata (that is to say, corrections) to the lecture notes posted on Tim Hoffman's course page as of 30 November 2005. I've organized the errata basically chronologically, but you don't need to read this page from top to bottom to get something out of it. Skip around! Look at the code samples! Have fun!
The code samples in this errata are color-coded; red text means an error to be deleted, and blue text means a correction to be inserted. The accompanying text usually explains why the correction is needed.
Now, on to the errata!
printf("Please enter an integer: ");
fflush(stdout);
But C's output is line-buffered, too. That is, if you try to print something to standard output, or to a file, it may not actually appear there until you also print a newline to that same device (which is called a stream, in C/Unix lingo). Then the full line appears "all at once" on the output stream.
But what if we don't want a newline in our output? Then we need to use the fflush function to "flush out" all the data written so far onto the screen, or into a disk file, or wherever it's going.
A note: The fflush function, as I described it, works only on output streams; those are the only streams where there's anything to "flush out." In fact, fflush is only defined to work on output streams; if you try compiling fflush(stdin) you'll get an error message at best, and undefined behavior at worse.
"Undefined behavior" is the technical term, in C, for "anything might happen." Two canonical examples of undefined behavior are dereferencing a null pointer and trying to evaluate an uninitialized variable. The two canonical results of these actions are to defrost your refrigerator and to cause demons to fly out of the user's nose. Compare the DeathStation 9000.
"Thus a #include increases the size of your compilation object..." This is unfortunate wording, since "object code" is something else in the C/Unix world, and #including header files doesn't generally increase the amount of object code produced. But the sentiment is right: Don't #include headers you don't need.
It's worth knowing that C does not specify the ASCII encoding for characters — a good thing, in this age of Unicode, but a much better thing back in the '70s, when each computer manufacturer had its own character encoding. The result is that if you want to write real, portable C code, you can't rely on things like 'A' being 65, or ')' being 1 greater than '('.
C does enforce a few constraints on the character encoding, though. For example, the digits are contiguous and in order: '7' == '0' + 7. The same can't be said of the letters, unfortunately. (This is because in one very common encoding of the '60s through '90s, EBCDIC, there really was a gap between the letters 'I' and 'J'! C was specified to work around that historical quirk, and others like it.)
Obviously, ints aren't always 32 bits — how could anyone write 64-bit code then? Likewise, char doesn't have to be eight bits (think Unicode!); in fact, none of the basic data types have any upper limit on their size. Again, there are a few constraints — but there's no need to get into them here. In this class, you may generally assume that int is "big enough," whether that be 16 bits, 32, or 1024.
The standard header <limits.h> provides a lot of macros, such as INT_MAX, which will yield the exact ranges of all the basic types. Thus we can write portably for any system:
int i = 2147483647;
int i = INT_MAX;
Plain char (yes, that's the technical term!) may be either signed or unsigned, depending on your compiler. If it matters, you can explicitly specify signed char or unsigned char, but in general you shouldn't be using chars to hold values that don't correspond to actual characters. As the lecture notes suggest, using char as a "small int" is possible, but terribly bad form.
Obviously, besides the four other possibilities mentioned in the notes, scanf might return EOF.
If you're using GCC for this course, you should always compile your code with
gcc -O2 -W -Wall -ansi -pedantic *.c
For the really assured, most Unix machines come with a program called lint or splint, which does clever code analysis to figure out a lot more of the sneaky errors. It can sometimes help with pinpointing memory leaks. Unfortunately, splint is an ultra-liberal when it comes to warning messages, so it will often throw a fit over perfectly correct code! This is why I say it's for the really assured: At some point, you have to be willing to say, "Yes, I know splint is warning me about this construct, but I know it's correct, anyway."
Generally, you should not use splint — especially not as a last resort! If you're so confused that you need splint's help, you're probably too confused to understand anything it's likely to tell you. Personally, I don't use splint.
Note that what the lecture notes call "strict C" is technically called "C89," or "C90," or "C95," or "ANSI C." However, the actual, current C standard is "C99," and it does allow some C++isms, including // comments and variable declarations in the middle of a block. Still, this course follows common industry practice in adhering strictly to C89. Don't use C++isms in your code.
The notion of "point type" is peculiar to our lecture notes. The technical term is "the type of the thing the pointer points to." No jargon needed... for once!
As with the basic types, there's nothing magic about pointers that requires them to be exactly 32 bits. In fact, many DOS systems have 16-bit pointers.
Dereferencing a null pointer does not halt the program; it invokes undefined behavior. Don't Do This.
The name of an array variable is not the same as the address of the first element of the array; at least, not in all cases! Consider the following code snippets.
#include <stdio.h>
int main(void)
{
char *p;
char arr[42];
printf("%d\n", (int) sizeof p);
printf("%d\n", (int) sizeof &arr[0]);
printf("%d\n", (int) sizeof arr);
return 0;
}
#define EXPECTED_CONVERSIONS 2
#define CONVERSIONS 2
So C has adopted a concept called reserved identifiers. Some identifiers (that is to say, variable names, but also names of functions, data types, macros, and other things) are simply reserved for future extensions to the language. We, as C programmers, aren't allowed to use them. Some of these reserved identifiers are more obvious than others. For example, we can't define a new function called strrev, because that might conflict with a future extension to the language. In fact, all names beginning with str and a lowercase letter are reserved. So are names beginning with to and a lowercase letter.
(But don't go changing everywhere you wrote int top; in your code. These restrictions generally only apply to names with global scope, not function parameters or local variables.)
The particular restriction here is on names beginning with a capital E followed by another capital letter. The fix? Get rid of the initial E!
But there's a deeper problem with the CONVERSIONS macro. After all, what is it being used for? It's being used in the getInts routine like this:
int getInts(int *a, int *b)
{
printf("Enter %d ints sep. by whitespace: ", CONVERSIONS);
fflush(stdout);
return scanf("%d %d", a, b) - CONVERSIONS;
}
The problem is this: Suppose we want to read three numbers instead of two. We might be tempted to #define CONVERSIONS 3 and recompile. But this wouldn't be good enough! We also need to go down to the getInts function and update the format string to scanf, from "%d %d" to "%d %d %d". (By the way, the spaces in that format string are unnecessary.)
And then, of course, we'd have to change the prototype and definition of getInts so that it took three parameters, and update any code that actually used getInts... The point is, there's no reason for CONVERSIONS to exist as a macro at all, since it's hard-coded in so many other places! If you mean "2", just write "2".
In the first sub-bullet on the page, "empty braces" should be "empty brackets." In the second sub-bullet, both "braces" should be "brackets."
In the fourth sub-bullet: The "array is a pointer" misconception has already been debunked. However, in some cases an array's name will evaluate to a pointer to the first element of the array. (Note that no pointer variable exists. This pointer is a pointer value, just like 42 is an integer value — the value of the address of arr[0].)
By now it should be clear precisely why you can't assign a new value to an array like this:
int arr[42], barr[42], *p = arr;
arr = 5; /* arr is not an int! */
arr = p; /* arr is not a pointer! */
arr = barr;
To copy one array over another, you can use
int arr[42], barr[42];
memcpy(arr, barr, sizeof barr); /* copy the whole array */
memcpy(arr, barr+10, 22*sizeof *barr); /* just 22 elements */
#ifndef H_BITAP
#define H_BITAP
#include
#define WORD_LENGTH 16
typedef struct bitap_info bitap_info;
struct bitap_info {
int matches;
int *pos;
};
int bitap_fsearch(FILE *fp, const char *key);
int bitap_search(const char *text, const char *key);
#endif
The #include directive is only there because otherwise the reference to FILE might not be recognized by the compiler (depending on whether the client code #included <stdio.h> before this file). In most of your work, the header files you write should not #include any other headers. The rule is: If you don't need it, don't drag it in.
A string in C is slightly more than an array of char — it's an array of char which contains a null terminator (the aforementioned '\0'). An array of characters that doesn't contain a null terminator isn't a string. For example:
#include <string.h>
int main(void)
{
char not_a_string[5] = "hello";
char buffer[42];
strcpy(buffer, not_a_string);
}
In "strings": The usual admonition about fflush applies to this code. Also, the usual admonition about buffer overflows applies to the scanf calls, but of course that's the point.
NULL is not the same as '\0', and shouldn't be used interchangeably with it. That's just gratuitously confusing. Also previously mentioned: C is not ASCII, so the explication of Question #2 is wrong for some platforms.
Still in "strings": The whole confusing, self-contradictory and incomplete explanation of const ought to be removed. Here's the real deal: const is a keyword in C (and C++) that means "Don't modify this." More specifically, if you see const in a variable or parameter declaration, it means "Don't modify the object to my right."
int sun;
int const life = 42;
int * const sunflower = &sun;
int const *finger = &life;
Contrariwise, finger is a non-const pointer to a const int. You can see this by looking at what's to the right of the keyword const in the declaration; it says, "Don't modify *finger." But as long as there's no const in front of finger itself, we're allowed to modify it.
The compiler will warn us — in fact, it will refuse to compile the code at all — if we try to assign to a const object, directly or indirectly. Also, note that sunflower cannot be made to point to life, because the compiler "knows" that *sunflower is modifiable and life is not.
Because the compiler enforces const so strictly, we can use its presence as a "contract" with the client, or with a library such as <string.h>. Since strcpy's second argument is declared as "const char *", we know that strcpy will never modify that argument's contents. This is an important guarantee to have!
You may be wondering what "const char *" means, anyway, since in that case the thing to the right of const is "char *". Well, that's a special case. If there's a typename to the right of const, then the declaration means the same thing as if you swapped the const and the typename: "const char *" means the same thing as "char const *" — it means, "Don't modify the characters this pointer points to."
In the description of strcmp, the first "strcpy" should be "strcmp". The key concept here is "lexicographic order" — lexicographic as in a dictionary. strcmp sorts "pear" before "pearl" and after "pea."
In "2D-strings1":
#define ROWS 3;
#define COLS 5;
#define ROWS 3
#define COLS 5
The mention of scanf should refer to strcpy instead.
I prefer to see words such as "command-line arguments" written out, not abbreviated as "cmd args" or other such l33tsp34k. That's just me.
This isn't a mistake in the notes, but I think it's worth mentioning the etymology of "argc" and "argv": You can think of the "c" as standing for "count" and the "v" as standing for "values." Thus argv is a pointer to the first element of an array with argc values in it, indexed 0 through argc-1.
In "fileIODemo1.c":
printf("Cannot open input file: %s", fileName);
while ((fscanf(inFile, "%s", wordBuffer) > 0) &&
(*wordCount < MAX_WORDS))
{
while ((fscanf(inFile, "%29s", wordBuffer) > 0) &&
(*wordCount < MAX_WORDS))
{
char spec[10];
sprintf(spec, "%%%ds", MAX_WORDLEN-1);
while ((fscanf(inFile, spec, wordBuffer) > 0) &&
(*wordCount < MAX_WORDS))
{
An alternative to testing strlen would be to truncate the input word, like this:
char wordBuffer[1000];
while ((fscanf(inFile, "%999s", wordBuffer) > 0) &&
(*wordCount < MAX_WORDS))
{
sprintf(dictionary[*wordCount], "%.*s", wordBuffer, MAX_WORDLEN-1);
*wordCount += 1;
}
"You could put both values in brackets but all you would accomplish is to restrict your function to accepting only a matrix of those exact dimensions." This is just plain wrong. The compiler will ignore the useless dimensional information. Remember, arrays in C are passed as pointers to their first elements; thus, all four prototypes
int foo(char a[5][7]);
int foo(char b[7][7]);
int foo(char c[][7]);
int foo(char (*d)[7]);
Man pages aren't much like an API (application programming interface). They're more like documentation. In fact, while it's common to hear programmers talk about the Java API, in C and C++ programmers typically refer to the standard library, and mentioning the "C API" will get you funny looks.
Strictly speaking, a FILE object in C is not a file handle. That phrase has a specific technical meaning on Unix and Linux systems; a FILE object may contain a file handle, but isn't one itself. (If you take 15-213, you will cover file handles in excruciating detail.)
return is not a function, and as such cannot be "called." (In fact, return is the keyword you use to do the opposite of "calling"!)
"Reading individual characters from the keyboard": See the page on safe input.
"If your program was hard to write it should be hard to read :-)". This, surprisingly, is good advice — and vice versa. If I'm reading your code, and I'm finding it hard to read, that should be a good indication that you found it hard to write. And if you had trouble writing it, that's probably because you didn't understand the material, and therefore deserve a poor grade on the lab. Conclusion: If your code is hard to read, your grade will suffer as a result. Don't say we didn't warn you. :)
Another comment in the same vein:
Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it.Yes, that is the Kernighan of "Kernighan & Ritchie."
One piece of advice on Lab 1: Not only should you be using a small input dictionary to start, you should be using a very small MAX_WORDS and MAX_WORDLEN, to make sure that your program handles bad input gracefully. In Lab 2, the same advice applies to INITIAL_LEN, so that you can easily see whether your array-resizing code works correctly.