Becoming proficient at debugging code doesn't end with learning to use a debugger like GDB—it begins there. There are a variety of other tools, both free and commercial, that also help to prevent, detect, and eliminate bugs in code. The savvy programmer keeps several of them in his or her bag of tricks, understands what each is good for, and recognizes when to use one of them to save time and effort if bugs appear.
So far we've focused our attention on using symbolic debuggers, but now we'd like to broaden our coverage to other aspects of debugging, including defensive programming. This chapter is devoted to some of the tools and techniques other than GDB that you may find useful, both to prevent bugs from arising in the first place and to find and fix them when they do.
The best debugging method is to not make programming errors to begin with! Simply making good use of an editor that has support for programming is one of the most overlooked aspects of "pre-debugging."
If you spend a lot of time coding, we urge you to think carefully about your choice of editor and to learn as much as you possibly can about the editor you will use. There are two main reasons. First, becoming proficient with a powerful editor decreases the time it takes you to write code. Editors that have specialized features, like automatic indentation, word completion, and global symbol lookup are a boon for programmers, and there are several to choose from. Second, a good editor can actually help the coder catch certain kinds of bugs as the code is being written. That's what this section is all about.
Both authors of this book use Vim for programming, so that's what we'll focus on. However, all the popular editors have similar, if not identical, feature sets. If Vim is enhanced to provide a useful feature not currently in Emacs, the community of Emacs developers would quickly rectify the situation, and vice versa. Therefore, although we give specifics for Vim, most of what we talk about applies to other excellent editors like Emacs as well.
Vim employs syntax highlighting to display portions of a program file with different colors or fonts, so that code elements like keywords, type identifiers, local variables, and preprocessor directives each have their own color and font scheme. The editor selects the color and font scheme by looking at the filename extension to determine the language you're using. For instance, if the filename ends with .pl (indicating a Perl script), occurrences of the word die (which is the name of a Perl function) are highlighted, whereas if the filename ends in .c, they are not.
A better name for syntax highlighting would be lexical highlighting, because the editor generally doesn't analyze syntax too closely. It can't tell you that you've provided the wrong number of arguments or arguments of the wrong type in a function call. Instead, it only understands (for example) that words like bless and foreach are Perl keywords and that fmt and dimension are Fortran keywords and displays them accordingly.
Even so, syntax highlighting is still very useful for catching simple but easy-to-make errors. For instance, on our computer the default color for type identifiers, like the FILE or float keywords in C, is green. Once your eye becomes trained to the font and color scheme, you'll catch the color inconsistency that arises when a type name is misspelled and automatically correct the mistake without having to go through a needless compile cycle.
An example of using syntax highlighting to check keywords that we (the authors) enjoy occurs with makefiles. The patsubst keyword is a very useful text search-and-replace command for makefiles. One of its most common uses is to generate a list of .o files from the .c files of a project's source code:
TARGET = CoolApplication OBJS = $(patsubst %.c, %.o, $(wildcard *.c)) $(TARGET): $(OBJS)
One of the authors can never remember whether it's patsubst, pathsubst, or patsub. Knowing that makefile keywords are displayed in a light color (yellow), can you figure out which version of the line shown below is incorrect? Even if you don't know how to write makefiles, syntax highlighting alone should make it clear! [16]
Furthermore, here's an example where syntax highlighting is a bit smarter. The figure below has an honest-to-goodness syntax error. Try to find, without thinking too much, what (or at least where) the error is, based on the colors alone:
and here's another illustration of a similar error. Try to let the color guide your eye to the error.
You may find that certain colors in the syntax highlighting scheme are hard to read. If so, you can turn off the highlighting by typing the following:
: syntax off
The command to turn it back on again is of course
: syntax on
A better option would be to modify the syntax file to use a different, better color for that type of keyword, but that's beyond the scope of our discussion here.
Unbalanced bracket errors are extremely common and can be very difficult to catch. Consider the following code:
mytype *myvar;
if ((myvar = (mytype *)malloc(sizeof(mytype))) == NULL) {
exit(-1);
}Note
In this section, the word bracket refers to parentheses, square brackets, and braces (or curly brackets): (), [], and {}, respectively.
Quickly: Are the parentheses balanced?[17] Have you ever had to track down unbalanced brackets in long blocks of code with lots of conditionals? Or tried to use TEX? (We shudder to think of some of our past LATEX files with missing braces!) Then you must agree with us that that's exactly what computers are for—to relieve us of such tedious work! Vim has some great features that can help.
Whenever you type a bracket at the keyboard, Vim's
showmatchoption makes Vim momentarily place the cursor over the matching bracket (if the matching bracket exists and is visible on the screen). You can even control how long the cursor lingers on the matching bracket by setting thematchtimevariable, which specifies this duration in tenths of seconds.Typing the percent symbol when the cursor is on a bracket will move the cursor to the bracket's mate. This command is a great way to track down unbalanced brackets.
When you place the cursor on a bracket, Vim will highlight its mate, as shown in Figure ??. This is also a great way to track down unbalanced bracket problems.
The showmatch option is useful when you're programming, but it can otherwise be annoying. You can use autocommands to set this option only when you program. For example, to set showmatch only for editing sessions with C/C++ source code files, you can put lines like these in your .vimrc file (see the Vim helpfiles for more information):
au BufNewFile,BufRead *.c set showmatch au BufNewFile,BufRead *.cc set showmatch
What if an unbalanced bracket enters your code, or worse, you need to catch unbalanced brackets in someone else's spaghetti code? The previously mentioned % editor command searches for balanced grouping characters. For example, if you place the cursor over a left square bracket, [, and type % from command mode, Vim will reposition the cursor to the next ] character. If you place the cursor on a right curly brace, }, and invoke %, then Vim repositions the cursor on the previous matching { character. In this way, you can verify not only that any given round, curly, or square bracket has a corresponding matching partner, but also that the partner matches semantically. You can even define other matching pairs of "brackets," like the HTML comment delimiters <!-- and -->, using Vim's matchpair command. See the Vim help pages for more information.
The make utility manages the compilation and building of executables on Linux/Unix systems, and a little bit of effort in learning how to use it can pay great dividends to the programmer. However, this also introduces new opportunities for errors. Vim has a few features that can really help in the debugging process if you use make. Consider the following makefile snippet:
all: yerror.o main.o gcc -o myprogram yerror.o main.o yerror.o: yerror.c yerror.h gcc -c yerror.c main.o: main.c main.h gcc -c main.c
There's an error in this makefile, but it's hard to see. make is very picky about formatting. The command line of a target must start with a tab character—not with spaces. If you issue the set list command from within Vim, you can see what's wrong immediately:
all: yerror.o main.o$ ^Igcc -o myprogram yerror.o main.o$ $ yerror.o: yerror.c yerror.h$ ^Igcc -c yerror.c$ $ main.o: main.c main.h$ gcc -c main.c$
In list mode, Vim displays nonprintable characters. By default, the end-of-line character shows up as $, and control characters are displayed with the caret symbol (^); thus, the tab character, which is CTRL-I, is displayed as ^I. Hence you can distinguish spaces from tabs, and the mistake is clear to see: The command line for the main.o make target begins with spaces.
You can control what is displayed by using Vim's listchars option. For example, if you want to change the end-of-line character to be = instead of $, you can use :set listchars=eol:=.
Invoking make from within Vim can be very handy. For instance, instead of manually saving your file and typing make clean in another window, all you need to do is type :make clean from command mode. (Make sure autowrite is set, so that Vim automatically saves the file before running the make command.) In general, whenever you type
:make argumentsfrom command mode, Vim will run make and pass arguments to it.
It gets even better. When you make your program from within Vim, the editor captures all the messages that the compiler issues. It understands the syntax of GCC's output and knows when a compiler warning or error occurs. Let's take a look at this in action. Consider the following code:
Example Listing 7-1. main.c
#include <stdio.h>
int main(void)
{
printf("There were %d arguments.\n", argc);
if (argc .gt. 5) then
print *, 'You seem argumentative today';
end if
return 0;
}It looks like somebody's been doing a little concurrent Fortran and C coding! Suppose you're currently editing main.c and want to build the program. Issue the :make command from within Vim and see all the error messages (Figure 7-4).
Now if you press ENTER or the spacebar, you return to editing the program, but with the cursor positioned on the line that generated the first warning or error (in this case, the message that argc was undeclared) as shown in Figure 7-5.
After you fix the error, there are two ways to proceed to the next error:
You could remake the program, and Vim will again display the remaining warnings and errors and reposition the cursor on the first one. This makes sense if the build time is negligible, especially if you map a single keystroke to build the program, for example, with:
au BufNewFile,BufRead *.c map <F1> :make<CR>
You could also use
:cnext, which displays the next error or warning. Similarly,:cpreviousdisplays the last error or warning, and:ccdisplays the current error or warning. All three commands conveniently reposition the cursor to the location of the "active" error or warning.
Becoming proficient with your chosen editor is so self-evident that it's often neglected, but it is really the first step in learning to program in a particular environment. At the risk of overstating things, editors are to programmers as musical instruments are to musicians. Even the most creative composers need to know the basics of how to play an instrument in order to realize their ideas so that other people can benefit from them. Learning to use your editor to its fullest extent enables you to program more quickly, figure out other people's code more effectively, and reduce the number of compile cycles you need to perform when debugging code.
If you use Vim, we recommend Steve Oualline's Vi IMproved—Vim (New Riders, 2001). The book is thorough and well written. (Unfortunately, it was written for Vim 6.0, and Vim 7.0 and later features like folding are not covered.) Our purpose here was just to give a taste of the things that Vim can do for the programmer, but Steve's book is a great resource for learning the details.
Vim has many features that the authors find obscenely useful. For example, we would have liked to cover
But this is a book on debugging, not on Vim, and we need to get back to discussing additional software tools.