22	Part I: Introduction to C Programming

After you reedit your source code file, you have to recompile to re-create the program file. That is how you fix an error or modify the program.

If you’re programming in an IDE (Integrated Development Environment) such as Dev-C++ or Microsoft Visual C++, you may need to use a Rebuild or Rebuild All command to create a new program after modifying your source code.

If you see any errors after recompiling, you must re-reedit your source code and then re-recompile again. (You only “reedit” and “recompile”; no sense in getting re-happy.)

Dealing with the Heartbreak of Errors

Errors happen. Even the best of programmers get errors, from the innocent code-writing cog at Microsoft to the sneering, snooty Linux programmer whose only contact with humanity is the pizza guy — they all get errors. Every day.

Errors are nothing to be embarrassed about. Consider them learning tools or gentle reminders. That’s because the compiler tells you, with uncanny accu­ racy, just what the error is and where it is. Contrast this with your most night­ marish math class: The wicked pedant would write only “WRONG!” next to your calculations, no matter how innocent a mistake you made. Yes, computers can be forgiving — and this can even teach you something.

Yikes! An error! But, before you shoot yourself. . . .

Here is a new program, ERROR.C. Note the optimism in its name. It’s a flawed C program, one that contains an error (albeit an on-purpose error):

#include <stdio.h>

int main()

{

printf(“This program will err.\n”) return(0);

}

Type the source code exactly as it appears here. Do not use the GOODBYE.C source code as a base; start over here with a clean editor window.

When you’re done entering the source code, save it to disk as ERROR.C. Com­ pile it, and then. . . .

Chapter 2: C of Sorrow, C of Woe 23

Unfortunately, when you compile this program, it produces an error. The next section provides the autopsy.

Pay careful attention as you type! Each little oddball character and nutty parenthesis is important to the C language!

Here’s a hint on the common GCC command to compile this source code: gcc error.c -o error

That’s the last compiling hint you get in this book!

The autopsy

The ERROR.C program erred! What a shock.

Don’t be alarmed — it was expected. (In fact, you may have seen this type of error before.) Here is a sample of what the cruel message may look like:

error.c: In function `main’:

error.c:6: parse error before “return”

How rude! It’s not that reassuring hand on your shoulder and the kind, avun­ cular voice explaining that you boo-booed. Still, what the error message lacks in personality, it makes up for in information.

On the up side, though the error message is cryptic, it’s informative. What­ ever your compiler, you should be able to single out the following bits of information:

The source code file that contained the error, error.c

The line that contains the error, Line 6 (though it may not be — you can’t really trust computers too much)

The type of error, a parse error or syntax error or something similar

The location of the error (before the word return)

It still may not be clear exactly what’s wrong, but you’re given many clues. Most important, you’re given a line number: The error is in Line 6.

Okay, it’s really in Line 5, but the C programming language is flexible, and the compiler doesn’t discover that “something’s missing” until Line 6. (You can cut the compiler some slack here.)

The error type is also important. A parse, or syntax, error means that an item of C language punctuation is missing, and, therefore, two things that aren’t supposed to run together have run together. In this case, a missing semicolon character at the end of Line 5 is to blame.

24	Part I: Introduction to C Programming

The solution? You have to reedit the source code file and fix what’s wrong. In this case, you would reedit ERROR.C and add the semicolon to the end of Line 5. Even if you looked at Line 6 (per the output’s insistence), you would see nothing wrong there. If so, your eyes would wander back and — because you’re aware of the Missing Semicolon Syndrome — you would see the prob­ lem and mend it.

Errors are not the end of the world! Everyone gets them.

Syntax refers to the way a language is put together. Some compilers use that term rather than parse, which means “the order in which things are put together.” Eh.

Some versions of GCC put double quotes around “return” rather than the tick marks shown in the preceding example. Beyond that, GCC is remarkably consistent with its error messages.

Missing semicolons are one of the most popular types of errors in the C language. You find out in the next chapter more about semicolons and the role they play.

The error message’s line number refers to a line in the source-code text file. That’s why nearly all text editors use line numbers, which you can see at the top or bottom of the screen or editing window.

The line number may or may not be accurate. In the case of a missing semicolon, the next line may be the “error line.” This statement holds true with other types of errors in C. Oh, well — at least it’s close and not a generic honk of the speaker and “ERRORS GALORE, YOU FOOL” plas­ tered onscreen.

A good habit is to fix the first error listed and then recompile. Often, the first error is the only real one, but the compiler lists others that follow because it becomes confused.

Of course, you may be thinking “Okay, smarty-pants computer, you know what’s wrong — fix it!” But computers don’t just jump to conclusions like that. That is the evil of the statement “Do what I mean”: Computers can’t read minds, so you must be precise. They are champs, however, at point­ ing out what’s wrong (and almost snobbishly so).

Repairing the malodorous program

To make the world right again, you have to fix the program. This process requires editing the source code file, making the needed correction, saving the source code file back to disk, and then recompiling.

Chapter 2: C of Sorrow, C of Woe 25

No need to fill your head with this

C programming has two degrees of errors: warnings and errors. Some compilers call the errors critical errors. (Sounds like a mistake Roger Ebert would make.) Other times, they’re fatal errors, like opening a creepy closet in one of those Scream movies.

The warning error means “Ooo, this doesn’t look tasty, but I’ll serve it to you anyway.” Chances are, your program runs, but it may not do what you intend. Or, it may just be that the

compiler is being touchy. With most C compil­ ers, you can switch off some of the more per­ snickety warning error messages.

The critical error means “Dear Lordy, you tried to do something so criminal that I cannot morally complete this program.” Okay, maybe it’s not that severe. But the compiler cannot complete its task because it just doesn’t under­ stand your instructions.

You can fix the ERROR.C program by adding a semicolon. Edit Line 5 and add a semicolon to the end of the line. Also correct the sentence displayed on the screen so that it reads as follows:

printf(“This program will no longer err.\n”);

Other than changing Line 5, everything else in the program remains untouched.

Save ERROR.C back to disk. Recompile the program and then run it:

This program will no longer err.

Indeed, it does not!

I can’t always tell you where to fix your programs. ERROR.C is the only program listed in this book that contains an on-purpose error. When you get an error message, you should check it to see where the error is in your source code. Then cross-check your source code with what’s listed in this book. That way, you find what’s wrong. But when you venture out on your own and experiment, you have only the error message to go by when you’re hunting down your own errors.

Pull two Rs out of ERRORS and you have Eros, the Greek god of love. The Roman god of love was Cupid. Replace the C in Cupid with St and you have Stupid. Stupid errors — how lovely!