Most Linux systems use glibc and therefore have qsort_r() and for the others an
implementation is provided, therefore there is no need to have a third case in
asort.

This avoids a warning on systems that have a 16bit wide mode_t.

Leave old hacky #ifdef tests there for reference.

tools/ccanlint/file_analysis.c needs to include config.h to set _GNU_SOURCE
before any other header file includes stdlib.h.

This is important because we tell people to use --failpath to reproduce a
failure, but the fail path we list only goes up to the last failure injection
if the child dies, for example.

Thanks to David Gibson for prodding me to fix this...

This allows for access to the end of the list, in case we need it
later (eg. moving free list entries to the end of the list after
failed coalescing?).

Turning getpagesize() into a constant 4096 really helps gcc optimize, and
not just on 64 bit.

Here are the results of running "tools/speed --transaction --no-sync 2000000":

i386 with gcc 4.4.5:
Before:
	$ ./speed --transaction --no-sync 2000000
	Adding 2000000 records:  1195 ns (93594224 bytes)
	Finding 2000000 records:  719 ns (93594224 bytes)
	Missing 2000000 records:  429 ns (93594224 bytes)
	Traversing 2000000 records:  523 ns (93594224 bytes)
	Deleting 2000000 records:  901 ns (93594224 bytes)
	Re-adding 2000000 records:  1032 ns (93594224 bytes)
	Appending 2000000 records:  1711 ns (182801232 bytes)
	Churning 2000000 records:  3233 ns (182801232 bytes)

After:
	Adding 2000000 records:  868 ns (93594224 bytes)
	Finding 2000000 records:  569 ns (93594224 bytes)
	Missing 2000000 records:  369 ns (93594224 bytes)
	Traversing 2000000 records:  406 ns (93594224 bytes)
	Deleting 2000000 records:  674 ns (93594224 bytes)
	Re-adding 2000000 records:  730 ns (93594224 bytes)
	Appending 2000000 records:  1144 ns (182801232 bytes)
	Churning 2000000 records:  2085 ns (182801232 bytes)

Here's the effect (average of 10) on x8664 with gcc 4.1.2, with an earlier
tree and 1000000:
	Before:
		Adding 830.1ns
		Finding 428.3ns
		Missing 250.3ns
		Traversing 387.4ns
		Deleting 588.8ns
		Re-adding 737.2ns
		Appending 1141.4ns
		Churning 1792ns

	After:
		Adding 562.8ns
		Finding 362.1ns
		Missing 226.4ns
		Traversing 276.5ns
		Deleting 426.7ns
		Re-adding 489.8ns
		Appending 736.4ns
		Churning 1112.7ns

We keep looking even if the current best is exactly right.  This is
really bad, because our smaller free lists hold exactly one size: with
this bug we iterate to the end of the list before hitting the end and
deciding we can use it after all.

Before:
	$ ./speed --transaction --no-sync 2000000
	Adding 2000000 records:  1179 ns (93594224 bytes)
	Finding 2000000 records:  694 ns (93594224 bytes)
	Missing 2000000 records:  429 ns (93594224 bytes)
	Traversing 2000000 records:  519 ns (93594224 bytes)
	Deleting 2000000 records:  896 ns (93594224 bytes)
	Re-adding 2000000 records:  1129 ns (93594224 bytes)
	Appending 2000000 records:  1713 ns (182801232 bytes)
	Churning 2000000 records:  32612 ns (182801232 bytes)

After:
	$ ./speed --transaction --no-sync 2000000
	Adding 2000000 records:  1195 ns (93594224 bytes)
	Finding 2000000 records:  719 ns (93594224 bytes)
	Missing 2000000 records:  429 ns (93594224 bytes)
	Traversing 2000000 records:  523 ns (93594224 bytes)
	Deleting 2000000 records:  901 ns (93594224 bytes)
	Re-adding 2000000 records:  1032 ns (93594224 bytes)
	Appending 2000000 records:  1711 ns (182801232 bytes)
	Churning 2000000 records:  3233 ns (182801232 bytes)

This helps us see where the problems are.

Running speed with --transaction --no-sync means no locking or syncs
are done, so we can measure raw TDB speed.

We use "r" after we call tdb_access_release() when we find corruption
in the free list.  "r" may be a pointer into malloced memory, freed
by tdb_access_release().

One but were we didn't update the map_size if we expanded the
transaction but didn't create a new recovery area (most easily
reproduced by setting the TDB_NOSYNC flag).

Another out-by-one bug in transaction_direct where we would give
read-access to the underlying file despite the last block having been
modified.

Both these were found by tdbtorture.

I'm still not sure it'll last into the final version, but finish the
implementation.

Samba uses these flags, so be friendly.

tdb1 has tdb_reopen/tdb_reopen_all, which you are supposed to call
after a fork().  But we can detect PID changes whenever we grab a lock,
which is to say, before we do anything.

We currently assume that pread and pwrite work, so the only problem
with fork() is if we are holding locks and expect them to still be
there in the child.  This is unusual, but most likely caused by a
fork() inside a transaction.  In such cases, allow the child to unlock
without complaint; they can then use the TDB as expected.

Performance before and after shows no measurable speed difference:

Total of 5 runs of tools/speed 100000:
Before:
	Adding: 18899ns
	Finding: 7040ns
	Missing: 5802ns
	Traversing: 6466ns
	Deleting: 12607ns
	Re-adding: 14185ns
	Appending: 20770ns
	Churning: 93845ns

After:
	Adding: 18073ns
	Finding: 6795ns
	Missing: 5549ns
	Traversing: 6333ns
	Deleting: 12313ns
	Re-adding: 13835ns
	Appending: 20343ns
	Churning: 92208ns

We also change tdb_chainunlock not to return an error (as per the
other locking functions: we log a message, but don't return an error).

This isn't on RHEL4, for example: isascii() and isblank() are not in
C89.

I don't quite know why, but this started happening to me.  We should
handle it anyway.

gcc gave a warning:
	tools/ccanlint/ccanlint.c:230:19: error: ‘c’ may be used uninitialized in this function

Which indicated that test dependency printing was broken: we need to
loop through the tests!  Also, we haven't parsed options yet, so
verbose is never true: move it to later and make it depend on -vvv.

memmem(), which searches for one bytestring in a longer
bytestring is one of those functions that should be standard, but
isn't.  This patch adds a ccan configurator test for the function
so that modules can use or replace it as necessary.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>

Simplest fix is to use const where possible, and use a different var for
asprintf and string literals in login.c.

Tests don't compile otherwise, so fix that up (ccanlint now tests with
reduced features, so this became clear).

Add a license tag (though it's a weird BSD variant), remove whitespace, and
avoid void pointer arithmetic.

They expect to be linked against the module objects.

Just grab the tokens for the simple case: this allows the ccanlint
reduce_features test to work on eg. ccan/cast.

This means we change some minor tests to "never fail", eg. whitespace
or documentation tests.  Note that pass/fail is independent of the
score for a test.

Be a little more careful with const.