"Linux Gazette...making Linux just a little more fun!"

The last article was on <stdlib.h> Standard Library.  This article is on <assert.h> Diagnostics for Programmers.

I am assuming a knowledge of c programming on the part of the reader.  There is no guarantee of accuracy in any of this information nor suitability for any purpose.

If used properly assertions will allow programmers to much more easily document and debug your code with no impact on runtime performance.  Assertions are not meant to be used for production code as they cause the program to terminate with an error condition.  Since assertions are never to be used in production code they are not useful in finding runtime errors such as a failure to allocate memory.  You must still handle failed return conditions of all function calls the same as always.

Instead, what assertions allow you to do is document the assumptions that you make as you program and allow you to debug the obvious logic errors that you have made.  As you program around these logic errors you can modify your assertions to not die on errors that you are now handling.

The example is rogers_example06.c .  In this program I will demonstrate the use of assertions by using a simple program that asks for two numbers and then divides the first number by the second.  Compile the program with the following:

gcc -DNDEBUG rogers_example06.c -o assert

and then run ./assert and try to divide by zero. The flag -NDEBUG will cause your assertion to generate no runtime code.  This flag should be used in all production environements

Your program will core dump with almost no indication of the problem.  Now recompile the program with the following:

gcc rogers_example06.c -o assert

Now run the program again and again try to divide by zero.  This time it should be much more apparrent what the problem is and very easy to locate the exact line that had the problem.

As always, if you see an error in my documentation please tell me and I will correct myself in a later document.  See corrections at end of the document to review corrections to the previous articles.

Assertions

A correction to Part *:
 

Bibilography:

The Standard C Library, P. J. Plauger, Printice Hall P T R, 1992

The Standard C Library, Parts 1, 2, and 3, Chuck Allison, C/C++ Users Journal, January, February, March 1995

STDIO(3), BSD MANPAGE, Linux Programmer's Manual, 29 November 1993