Aerospace Software Ltd.

Safe C How-to Guide

For Mandriva Linux 2006

Scope

This guide describes some simple defences against unsafe coding practices. There are quite a few C library functions that are unbounded, which can cause memory problems and buffer overflows. This stupidity dates back to the carefree beginnings of C. This guide describes a simple header file that can be included to guard against the most egregious troublemakers.

Another problem is the C++ extensions. These extensions introduce the idea of dynamic objects that can be readily created and destroyed. The only problem is that there is no definitive way to know when it is safe to destroy an object! The solution is to use a garbage collector. Hans Boehm at HP, created a conservative garbage collector for C which is used in many programming projects, including the compiler GCC.

Unsafe Functions

Most C troublemakers are in the strings library. Traditionally, C uses NULL terminated strings - a horribly bad idea, given 20-20 hindsight. These functions now all have new versions that are bounded with the addition of a length parameter.

For example, strcpy() has been replaced with strncpy(). The remaining problem therefore is one of preventing the inadvertent use of the old troublesome functions. This can be easily achieved by including the following header file in your project:

/*
 * File banned.h
 * This header file redefines unbound and unsafe functions
 * For example, instead of strcpy(), rather use strncpy()
 */

#define strcpy(a, b)		exit(1001)
#define strpcpy(a, b)		exit(1002)
#define wcscpy(a, b)		exit(1003)
#define wcpcpy(a, b)		exit(1004)
#define strcat(a, b)		exit(1005)
#define wcscpy(a, b)		exit(1006)
#define getwd(a)		exit(1007)
#define gets(a)			exit(1008)
#define fscanf(a, b, c)		exit(1009)
#define vscanf(a, b)		exit(10010)
#define realpath(a, b)		exit(10011)
#define sprintf(a, b, c)	exit(10012)
#define vsprintf(a, b, c)	exit(10013)

The result is that anyone that uses a banned function is in for a little surprise and will quickly learn not to use them!

Garbage Collection

The C++ extensions introduce the idea of dynamic objects that can be readily created and destroyed. The only problem is that there is no definitive way to know when it is safe to destroy an object! The solution is to use a garbage collector. Hans Boehm at HP, created a conservative garbage collector for C which is used in many programming projects, including the compiler GCC.

Get the conservative garbage collector here: http://www.hpl.hp.com/personal/Hans_Boehm/gc/

You can read why using this device is a really good idea, here: http://www.hpl.hp.com/personal/Hans_Boehm/gc/issues.html

Using this garbage collector is very simple. Link the DLL into your project and instead of calling malloc(), you call GC_malloc() and you never need to call free(). In an existing project, the conversion can be done with simple macros:

#define		malloc(a)		GC_malloc(a)
#define		malloc_large(a)		GC_malloc_ignore_off_page(a)
#define		free(a)			(a = NULL)

As soon as you start using this garbage collector instead of the standard memory manager, you may very well find that some weird and wonderful bugs in your project simply disappear.

Note that while use of this garbage collector will stabilize the memory consumption of a C++ project, you still cannot accurately predict the worst case memory use. Therefore, even with the addition of the garbage collector, you still cannot use C++ in safety critical applications and there will always be a requirement for ANSI C in airborne applications for example.

La Voila!