Comp210 Lab 13: C Errors and Debugging

Compile-time Errors, Run-time Errors, Debugging

As in DrScheme, you can encounter errors at two times:

during compilation (prior to compiling, it first performs the equivalent of DrScheme's Check Syntax) and
while running (the equivalent of DrScheme's Execute).

At least in principle, C/C++ can find more mistakes than Scheme during compile-time, as it looks for type-errors. However, C/C++ run-time errors are generally very uninformative. During this section of lab, we will give you a quick introduction to diagnosing and fixing some of your errors.

To labbies: There's no need to get through all examples in lab.

Compile-time errors

To do: Copy the program /home/comp210/public_html/Labs/lab13/sampleerr.cc into your directory and compile it. It complains
sampleerr.cc: In function `int main()': sampleerr.cc:9: `x' undeclared (first use this function) sampleerr.cc:9: (Each undeclared identifier is reported only once sampleerr.cc:9: for each function it appears in.) sampleerr.cc:13: `Y' undeclared (first use this function) sampleerr.cc:20: parse error before `<' sampleerr.cc:31: parse error at end of input
A number just after the file name indicates the line number in the file where this error occurs. I.e., in the function main, the variables x and Y are used in lines 9 and 13, respectively, but neither have been declared. Also there is a syntax error just before the closing brace on line 6. For this first example, comments in the code tell you how to fix the problems. Fix some or all of the problems, recompile, and see if you still have any more errors.

To do: Copy the program /home/comp210/public_html/Labs/lab13/error1.cc into your directory and compile it. It complains
error1.cc: In function `float c2f(float)': error1.cc:6: parse error before `}'
Any time it complains about a "parse error", that means you've left something out that is necessary (like a comma or semicolon or keyword), put something extra in, or mistyped something (like misspelling a keyword).

To do: Copy and compile the program /home/comp210/public_html/Labs/lab13/error2.cc. It complains
error2.cc:3: parse error before `(' error2.cc: In function `int main(...)': error2.cc:13: warning: `float' used for argument 1 of `c2f(int)'
The second two lines of errors mean that in the function main, on line 13 we call the function c2f with a float, but it expects an int. Can you fix the problems?

For the curious: This error is just a warning because C/C++ lets you get away with things like this -- it will automatically convert the float to an int. In some other languages, this is a true error and not just a warning. Try running the result. It works, except that it truncates the input to an integer. (Note also that it uses integer division for c/5, i.e., it truncates that intermediate result, too.)

To do: Copy and compile the program /home/comp210/public_html/Labs/lab13/error3.cc. It complains
error3.cc: In function `int main(...)': error3.cc:10: `cin' undeclared (first use this function) error3.cc:10: (Each undeclared identifier is reported only once error3.cc:10: for each function it appears in.) error3.cc:10: `c' undeclared (first use this function) error3.cc:11: `cout' undeclared (first use this function) error3.cc:11: `endl' undeclared (first use this function)
I.e., there are a bunch of things which haven't been properly been declared/defined/introduced. Look at the program -- can you identify what these errors are complaining about and what caused them?

To do: Copy and compile the program /home/comp210/public_html/Labs/lab13/error4.cc. It complains
error4.cc: In function `int main(...)': error4.cc:12: no match for `operator <<(class _IO_istream_withassign, float)'
I.e., in the function main, on line 12, there is no definition of << appropriate for its use. Can you find the error?

For the curious: This is basically shows that input stream cin and output stream cout are not of the same type. Furthermore, the message shows that cin is an object, as its type is a certain class. Although we won't be introducing C++'s objects in this course, we are actually using some of the predefined ones.

To do: Ok, now for the big event. Copy /home/comp210/public_html/Labs/lab13/error5.cc to your directory. Compile it -- it reports an error, so you need to fix it. Now try compiling it -- it reports some more errors! The first time around, the compiler became sufficiently confused by the first error that it gave up looking for any more. Now that you've fixed that, it looked for and found more errors. You need to fix these. Repeat until you get a working (if silly) program.

Run-time errors

All of the previous errors have been found during compilation. Give what we have seen of C/C++ so far, it's pretty hard to have a run-time error, assuming you follow your program templates. (This ignores the possibility that your program may compute something correctly, just not the right thing.)

To do: Look at and compile /home/comp210/public_html/Labs/lab13/sumsquares.cc. This will sum the squares of all integers in an interval. Run the compiled program. What do you get on inputs 10 10000? It overflows and doesn't tell us about it. Change the program to use floats and try it.

For the curious

To do: Look at and compile /home/comp210/public_html/Labs/lab13/ack.cc. This is a funky function called Ackerman's function. The result of this can easily be a really big number, so we use floats instead of ints. Run the compiled program:

% ack 3 2 4

We can hand-evaluate this to see that ack(3,2) = ack(2,ack(3,1)) = ack(2,2) = ack(1,ack(2,1)) = ack(1,2) = ack(0,ack(1,1)) = ack(0,2) = 2*2 = 4.

% ack 3 3 65535

Ok, we'll take the program's word for it -- it's right. I told you the results get big quick.

% ack 3 4 Segmentation fault

Huh?!? This error means that something really bad happened and the computer got VERY confused. Basically, we made more recursive function calls than C/C++ would allow us. To get a more complete answer, take Comp320. Scheme doesn't have this same limitation (cf. Comp311), but it's rare to run into this problem.

Debugging

Debugging a C program can be more difficult that debugging a Scheme program because we don't have the equivalent of Donkey to step through our programs. In this part of the lab, we will find and fix some program errors. These will be examples of some of the common C programming mistakes.

Q / To do: What does this program in /home/comp210/public_html/Labs/lab13/debug1.cc do? Can you fix it so it does the intended calculation? Edit, compile, and run it until it does what you expect.

For small programs like this, it's often not too difficult to step through the evaluation either in your head or on paper. But errors can be hard to find, especially when you "know" that your program is "obviously" right. One technique for effectively stepping through the interesting bits of the computation is to print some interesting values while your program is running. We saw this before for Scheme also.

To do: Copy, compile, and run /home/comp210/public_html/Labs/lab13/debug1print.cc, which is like the previous program, except that we print out some values along the way.

Did you find the uninitialized accumulator and the incorrectly ordered side-effects?

Good places to print out values include

the beginning of a function, to see if you are passing in the values you expect,
the end of a function, to see if you are returning what value and when you expect,
the beginning and end of a loop (since loops are just a special case of a function),
after a bunch of assignments, to see if your assignments did what you expected, and
the branches of a conditional, to see if you took the expected branch.
However, you can easily get carried away. In larger programs, it's generally a good idea to start with the beginning and end of functions, to first track down which function your problem is in. Then pay more attention to the body of that particular function. I.e., break down the problem of debugging into manageable chunks, just like you do for programming.

There are ways to extend this technique, e.g., having multiple "levels" of debugging which print out different amounts of information. Also, there really are some tools that help you step through C programs (e.g., gdb, adb). With practice, these can be very helpful, but they aren't as easy to use as Donkey.

To do: Now try /home/comp210/public_html/Labs/lab13/debug2.cc. Hint: assignment vs. equality test.

To do: Now try /home/comp210/public_html/Labs/lab13/sumarray.cc. This is supposed to sum the integers in a specific array.

To do: Now try /home/comp210/public_html/Labs/lab13/debug3.cc. Hint: off-by-one, using wrong variable.