OpenBSD-4.6/gnu/usr.sbin/sendmail/libsm

libsm Overview

$Sendmail: index.html,v 1.14 2001/02/13 21:21:25 gshapiro Exp $

Introduction

Libsm is a library of generally useful C abstractions. Libsm stands alone; it depends on no other sendmail libraries, and the only sendmail header files it depends on are its own, which reside in ../include/sm.

Here is the current set of packages:

gen: general definitions
debug: debugging and tracing
assert: assertion handling and aborts
heap: memory allocation
exc: exception handling
rpool: resource pools
cdefs: C language portability macros
io: buffered i/o

Naming Conventions

Some of the symbols defined by libsm come from widely used defacto or dejure standards. Examples include size_t (from the C 89 standard), bool (from the C 99 standard), strerror (from Posix), and __P (from BSD and Linux). In these cases, we use the standard name rather than inventing a new name. We import the name from the appropriate header file when possible, or define it ourselves when necessary. When you are using one of these abstractions, you must include the appropriate libsm header file. For example, when you are using strerror, you must include <sm/string.h> instead of <string.h>.

When we aren't implementing a standard interface, we use a naming convention that attempts to maximize portability across platforms, and minimize conflicts with other libraries. Except for a few seemingly benign exceptions, all names begin with SM_, Sm or sm_.

The ISO C, Posix and Unix standards forbid applications from using names beginning with __ or _[A-Z], and place restrictions on what sorts of names can begin with _[a-z]. Such names are reserved for the compiler and the standard libraries. For this reason, we avoid defining any names that begin with _. For example, all libsm header file idempotency macros have the form SM_FOO_H (no leading _).

Type names begin with SM_ and end with _T. Note that the Posix standard reserves all identifiers ending with _t.

All functions that are capable of raising an exception have names ending in _x, and developers are encouraged to use this convention when writing new code. This naming convention may seem unnecessary at first, but it becomes extremely useful during maintenance, when you are attempting to reason about the correctness of a block of code, and when you are trying to track down exception-related bugs in existing code.

Coding Conventions

The official style for function prototypes in libsm header files is

extern int
foo __P((
	int _firstarg,
	int _secondarg));

The extern is useless, but required for stylistic reasons. The parameter names are optional; if present they are lowercase and begin with _ to avoid namespace conflicts. Each parameter is written on its own line to avoid very long lines.

For each structure struct sm_foo defined by libsm, there is a typedef:

typedef struct sm_foo SM_FOO_T;

and there is a global variable which is defined as follows:

const char SmFooMagic[] = "sm_foo";

The first member of each structure defined by libsm is

const char *sm_magic;

For all instances of struct sm_foo, sm_magic contains SmFooMagic, which points to a unique character string naming the type. It is used for debugging and run time type checking.

Each function with a parameter declared SM_FOO_T *foo contains the following assertion:

SM_REQUIRE_ISA(foo, SmFooMagic);

which is equivalent to

SM_REQUIRE(foo != NULL && foo->sm_magic == SmFooMagic);

When an object of type SM_FOO_T is deallocated, the member sm_magic is set to NULL. That will cause the above assertion to fail if a dangling pointer is used.

Additional Design Goals

Here are some of my design goals:

The sm library is self contained; it does not depend on any other sendmail libraries or header files.
The sm library must be compatible with shared libraries, even on platforms with weird implementation restrictions. I assume that a shared library can export global variables; the debug package relies on this assumption. I do not assume that if an application redefines a function defined in a shared library, the shared library will use the version of the function defined in the application in preference to the version that it defines. For this reason, I provide interfaces for registering handler functions in cases where an application might need to override standard behaviour.
The sm library must be compatible with threads. The debug package presents a small problem: I don't want sm_debug_active to acquire and release a lock. So I assume that there exists an integral type SM_ATOMIC_INT_T (see <sm/gen.h>) that can be accessed and updated atomically. I assume that locking must be used to guard updates and accesses to any other type, and I have designed the interfaces accordingly.