UNDERLYING DATABASE LIBRARIES
-----------------------------

This package has been tested with three sets of database routines, one
of which in two modes:

* GNU/FSF's dbm library using gdbm and its ndbm wrapper. (v1.5 - v1.7.3)
* Ultrix OS's native libdbm implementation of ndbm. (v?)
* Berkeley's db library using its ndbm wrapper. (v1.79)

The gdbm library is included in libc-4.x.x on Linux systems (although
a rather out of date version is bundled with libc-4.5.26)

As an underlying part of this package, choice of database routines is
fairly important. gdbm v1.5 (the default for Linux users) is fairly
fast, but for added speed, in some circumstances gdbm v1.6+ can be
used, which has the bonus of being able to perform unsynced writes.

The Berkeley implementation appears to be even faster, although it's
lack of syncs may lead to corruption of the database if a program
using the routines dies unexpectedly. The documentation included with
the library routines is rather sparse but it looks like a future
version may also provide LIBTP 'transactions', which would allow
multiple write access to the databases not currently available with
any of these implementations. I'm unsure if this package actually does
any file locking at the moment, and if not, it would make multiuser use
very unhealthy for the databases.

As of this release, attempted concurrent database updates with other
updates or even reads will cause man to retry several times,
sleep()'ing between tries. If still unable to gain control of the
database, man will terminate with a 'Try again' message or something
similar (depending upon particular version).

Externally, gdbm and 'ndbm implementations' are similar except for the
way in which they allocate memory. gdbm allocates memory with malloc()
each time a key/content pair is accessed and it is up to the
programmer to free the area. This is good if you want to 'keep' some
data pairs whilst accessing other key/content pairs. ndbm has a single
static storage area that it overwrites each time a data pair is
accessed, thus retrieved data that may need to be reused, must be 
strdup()'d or saved elsewhere, otherwise it will change the next time 
any database is accessed.

UNDERLYING REGEX LIBRARIES
--------------------------

Regex routines are used by the whatis side of this man package. Two
implementations have been tried under varying conditions.

* FSF/GNU's regex.c, regex.h (0.12)
* Tom Lord's (FSF/GNU) rx.c, rx.h (v0.03 - 0.05)

Again, Linux users will find that regex.c is part of their libc. If
man is linked with shared libraries and regex.c is replaced with rx.c
in a future shared library, re-compilation will be necessary as some
internal structures differ, whose sizes are required at compile time.

There are three regex styles available with regex.c: a native version,
a POSIX version and a BSD version. Currently only the POSIX version
has been coded for in man.

regex.[ch] has been bundled with this package for portability reasons
until such a time as support for BSD style regex is added.

As far as speed is concerned some strange results have been
noticed. The general opinion is that rx.c is faster but the way in
which man uses the routines cause regex.c to be some 13% faster than
the newest rx.c. Also (under Linux), gcc's -O flag produces faster
executing code than -O2.
