This is a fairly sophisticated use of failtest:
1) There are a few places where we can inject failures without revealing it
   at the API level, eg. opening /dev/urandom, or allocation failure in logging.
2) We want to be sure that (almost) all failures cause a message to be logged.
3) We need to exit as soon as possible when a failure is injected, to avoid
   combinatorial explosion.
4) We don't want to simply exit on any log message, since we want to be sure
   that cleanup happens.

This test found four different bugs failure paths.  Erk!

Since failtest uses macros to override read and write, we need to avoid
those names, even inside our ops structure.

On normal files, pwrite and write should never return short except on error.
As we never create sparse files, so any short write is an I/O error.

Simply assume that any short read on a TDB in an I/O error.

Do it properly, with a printf-style interface.

Especially since they probably define _GNU_SOURCE.

Otherwise we don't get goodies like asprintf, and 64-bit offsets.  Should
be a harmless-define on non-glibc systems.

We run in a temporary directory now.  Also, avoids warning and memory leak.

And use those names, too.

Old habits die hard; it's better to use #if <FEATURE> than #ifdef <FEATURE>;
they're similar, because undefined identifiers evaluate to zero, but with
GCC's -Wundef flag you can detect mis-spelled or missing features with
#if.

autoconf-style config.h leave unset features undefined, so this works for
those config.h too.

A common mistake is not to try compiling with features disabled in
config.h.  The ideal case would determine how features interact and
test all combinations of them: this simply disables any features
mentioned in the code which were previously enabled.

This means you don't have to recompile ccanlint to get the new flags;
it's a small step towards making ccanlint useful outside the ccan repo.

David Gibson reports (and I confirmed) that running ccanlint in /tmp
causes an very uninformative segv.  Fix that, and add a more useful message,
as well as delaying recursing until we're confident there's code around.

Andreas Schlick reports that PaX et. al. dislike trampolines, so open-code
qsort from glibc.

Interestingly, _quicksort from glibc seems to have a void * parameter, but
I can't find any information on it.

We need to get the locks back *after* the child runs.

Aborts on a short write with --tracepath.

This isn't a general requirement for CCAN modules, but Samba uses it, so
make sure tdb2 doesn't upset it.

Samba (for example) uses a DEBUG() macro, which triggers these heuristics.
Better to make it per-module anyway.

When I changed score_file_error() to printf-style, I didn't audit all
the callers who were handing string literals.  I've finally done that;
I should have broken the compile by renaming it.

Rusty fails refactoring 101.
Reported-by: Andreas Schlick

 * Removed talloc support.
 * Added a synopsis and rearranged macro definitions.
 * Switched allocation strategy from increments of 64 to powers of 2.
 * Replaced array_for and array_rof with the more useful
   and portable macros array_foreach and array_foreach_reverse.
 * Added typedefs array_* for common types.

If we need to clean up the children, they didn't exit cleanly.

This takes a bit more care when writing tests, but found a leak in tdb2.

tdb2 has various places where it recovers from failure (eg. falling
back when it can't open /dev/urandom, or allocation for error
logging).  We want to test those paths, but doing so thoroughly causes
cominatorial explosion.

Add FAIL_PROBE for such cases: in this case it goes only 3 more calls
deep.

We trap them, might as well put them in history.  This also makes tracking
open file descriptors more robust.

ie. SIGUSR1 means it timed out.

If children and parents aren't isolated properly (ie. failtest is
buggy) we really want to run gdb on a failing child.  This hack allows that.

open fails in fairly normal cases; don't double execution time for this!

We insist they write the same things to pipes, since we can't "undo" them,
but strictly speaking we don't care if they write different things into
files.

Note: it may indicate a bug if they do...

The idea of saving files as we do writes doesn't work with mmap: this just
saves the entire contents of all open files before forking child, and
restores them afterwards.