# libsm Overview

$Id: index.html,v 1.1.1.1 2002/03/12 18:00:20 zarzycki 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`.

## Contents

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.