COMPILE-TIME ERRORS
The compiler makes several passes through the code during compilation. The actual number of passes depends on the compiler, but most compilers make three or four. Bugs are usually discovered only in the first two passes. The first pass, made by the preprocessor, expands macros and reads in-eluded header files or other source files. In the next pass, the parser and lexical analyzer attempt to understand and produce cede from the source statements. Most of the error messages are generated during this second pass.

The following are simple examples of compile-time errors:

• Invalid preprocessor directives (#page: 7)
• Illegal operator use (&a=123;)
• Illegal symbol or identifier name (byte j;)
• Illegal punctuation or character (j=0:)
• Illegal language grammar (if j==0 then j=3;)
• Incompatible type operation (*r = r;)
• Invalid symbol or number (int 23skidoo;)

For the most part, these bugs result from types or errors made by a programmer still learning C and are classified as syntactical bugs. Stabilizing these bugs isn't an issue since the bug recurs each time the file is compiled.

Localization of a compile-time error is usually fairly easy, although occasionally a bug (such as an open comment) may require a little work to localize. Once the bug is localized, it's usually simple to correct.

LINK-TIME ERRORS
The linker's job is to connect other (hopefully tested) modules to the program and build an executable entity. It's possible that one or more of the modules linked to the target program will be either test routines capable of exercising the target program or stub modules simulating a section of code yet to be written.

If link-time errors are detected, most likely the linker couldn't find all the parts or libraries required to build the final program or couldn't understand the object modules representing the program due to incompatible format. (These problems are usually also reported by the compiler.) In either case, the error is in the commands to the linker or the format of the object module, not bugs in the program. Only rarely, such as when a library function name is misspelled, can a bug cause link errors.

RUN-TIME ERRORS
At this point, the programmer has succeeded in getting the program to compile. This accomplishment doesn't mean that the program is free of typos or incorrectly formed statements; it simply means the compiler didn't detect them.

Now we come to the difficult bugs. Run-time bugs that exist without catastrophic results--the program will run but does the wrong things--are intent errors; those that cause the program to terminate abnormally are execution errors.

An intent error occurs whenever a program runs to normal completion but produces incorrect results. Examples of intent errors are one-liner, typematch, boundary, macro, and design bugs.

The simplest intent error is the one-liner, a syntactically correct statement that has an error in it. These errors are usually caused by an incorrect assumption regarding operator precedence, an incorrect choice of operator, or misplaced or missing punctuation. These errors, which I call "awshitical" bugs (based on mutterings from programmers who have spent considerable time staring right at the erroneous statement without seeing the bug), are a subclass of intent bugs. Here are a few:

if (i=1) {...}

Dang, we wanted to compare i, not assign to it. The if condition will always be true.

if (i==1); {...}

Oops, we put a semicolon after the if statement. The if has no effect on the body of statements that follow.

while (c = getchar() != 0) {...}

We forgot operator precedence; c will be 1 or 0. What we meant to write is ((c=getchar()) != 0).