then you have probably interchanged some variables in your program. Your program may also say something like

This was the result of having an integer (4 bytes in this case) and a double precision floating-point variable (8 bytes) in the wrong order as arguments to a printf function (see below). The program treated the first four bytes of the 8-byte floating-point as if it were an integer and then took the remaining eight bytes --- the last four bytes of the double plus the following integer --- as a floating-point number, with the resulting disfunctional display.

Incidentally, the two lines aboves were output from the C program

and then ran c_what1, you would get the output above with no warning. However, if you had compiled the program using

then you would get several warning messages about printf arguments not matching the variables in its format string. These would have been a clue to fix the printf statements. (Incidentally, the -W   in -Wall stands for Warning and all for All, so that -Wall is not a reference to a real wall.)

A more insidious example is the C program

which had output

The reason for this curious output is that `xx' is initialized at 7 (so that xx=7 until it is changed), but the variable in the second printf statement is x, not xx. In this case, x was declared but not initialized, and that location in memory happened to have the value 2 when the program was run. This sort of error is hard to detect and can occasionally cause believable but highly incorrect results.

However, if you had compiled this program as

then you would have gotten a warning message that `xx' was given a value but that value was never used. The latter suggests that you made an error of exactly this sort.

there would have been absolutely no warning or error messages.

In C, text strings are handled as pointers to arrays of variables of type char (usually one byte each) that end with a zero byte. In this case, the compiler creates an array of 6 bytes that has Hello as its first 5 characters and then 0 to end the text string. The program then stores the address of this array in the variable str.

Crashing program bugs:

The first two statements above are called range errors (for obvious reasons). The third is an overflow error, since exp(500000) is too large to store in a double-precision floating point number. The opposite condition

does not generally cause any problem: The computer normally replaces w by 0.0 and proceeds, although there may be problems later if you say 1/w. (A command like exp(-500000) is called an underflow, in contrast to exp(500000), which causes an overflow.)

Treatment of math exceptions:  By convention, modern C compilers handle math exceptions without program interruptions. The resulting floating-point numbers is replaced by what are called Infs (standarding for ``infinities'') or NaNs (standing for ``Not a Number''). Any further numerical operation on an Inf or NaN produces another Inf or NaN. When you try to display an Inf or NaN in a print statement, it shows up in computer output as something like #INF or #IND (the latter for Indefinite).

Redirecting signals:  The problem remains of how to handle serious signal errors such as segmentation faults. You can get rid of the irritating drop-down windows for these signals, or for most of them, by ``installing your own signal handler''. An example of how to do this is given in the following program.

The main() program above shows two apparent problems. The first print statement has a division-by-zero error in computing miles per gallon. However, in most modern C compilers, this generates a NaN instead of an unhandled exception. The program displays #INF for miles per gallon and proceeds. (The older Borland C Vs. 5.0 compiler generates an FPE signal error at this point.)

NOTE  If you include the file statlib.c on the Math408 Web site in your program, as well as the header filestatlib.h, then you can install essentially the same signal handler in your program by putting the single command

in your program, in place of Step III. (Note this is set_newsignals(), not set_mysignals().) Then leave out Steps I, II, and IV above. (That is, you can leave out the code for my_signal_handler() and set_mysignals().)  The necessary prototypes are in statlib.c and statlib.h, and the code for set_newsignals() and the signal handler itself are in statlib.c.