NOTE: btree was originally copyright 2010, and has not been
touched by me since then.  I don't know if changing the license
to something more permissive requires updating the copyright year
or not.

NOTE: block_pool was originally copyright 2009, and has not been
touched by me since then.  I don't know if changing the license
to something more permissive requires updating the copyright year
or not.

No point checking malloc failure in usage(), since we don't elsewhere.
We get 100% coverage with -O (due to code elimination) or 64 bit.

In particular, handing an pointer to ULL where a pointer to UL is expected
won't work on big endian.

As with the set_ functions, there are twelve permutations of integer size,
base, and signedness.  The supported sizes are int, long, and long long.

For example, this:

 char buf1[OPT_SHOW_LEN];
 char buf2[OPT_SHOW_LEN];
 unsigned i = 1024000;
 opt_show_uintval_bi(buf1, &i);
 opt_show_uintval_si(buf2, &i);

will put "1000k" in buf1, and "1024k" in buf2.

Unlike the opt_set_ functions, these use unsigned arithmetic for unsigned values.

(32 bit bug using sizeof(suffixes) instead of strlen(suffixes) fixed by Rusty)

This comment occurred in a couple of places:

 /* Set an integer value, various forms.  Sets to 1 on arg == NULL. */

One instance was clearly spurious, while the other was misleading.

Another resolution to this mismatch would be to add
"if (arg == NULL){*l = 1; return NULL}" somewhere, but I suspect
it may have been left out/removed because someone thought better.

These functions come in two flavours: those ending with "_si", which
have 1000-based interpretations of the suffixes; and those ending with
"_bi", which use base 1024.  There are versions for signed and
unsigned int, long, and long long destinations, with tests for all 12
new functions.  The tests get a bit repetitive, I am afraid.

As an example, if the -x option were using the opt_set_intval_bi
function, then all of these would do the same thing:

$ foo -x 5M
$ foo -x $((5 * 1024 * 1024))
$ foo -x 5242880
$ foo -x 5120k

quite what that thing is depends on the size of your int -- people
with 16 bit ints would see an "out of range" error message.

The arithmetic for unsigned variations is actually done using signed
long long integers, so the maximum possible value is LLONG_MAX, not
ULLONG_MAX.  This follows the practice of existing functions, and
avoids tedious work.

We were missing failed tests: if the top-level returns FAIL_PROBE, we would
exit; this should only apply to children.

Kirill A. Shutemov asked for libgit.  I would say they should upgrade their
license, but libhx on which these are based is also LGPLv2.1 or later, so
I prefer to match that.

The recently added ccanlint licensing checks revealed several cases
where the published license of a module is misleading: a dependency of
that module has a stricter license (eg. a public domain module which
depends on a GPL one).

Where these are my modules, I've fixed them.  Otherwise I'm overriding
the checks for the moment, and asking the authors what they want to do.

We don't correctly detect pure-comment lines in ccan/ttxml/ttxml.c
without this.

This is for SAMBA, so we follow their rules and do full license
headers.  Two files were missing them.

Too trivial to deserve LGPL, and all my code.

Too trivial to deserve LGPL, and all my code.

Various LGPL components depend on it, via ccan/likely.  ccan/likely
really only needs it when CCAN_LIKELY_DEBUG is set, but making it a
conditional dependency is a bit nasty if defining that changes the
license.

So this is the simplest fix.  I might relicense under PD or BSD later,
since the likely module should probably have an even more liberal
license.

We don't check external dependencies, but internal ccan deps are
pretty easy.

Refactoring helps the next patch.

Comments in code indicate this is actually GPL version 2 or later.

Comments in code indicate this is actually GPL version 2 only.

As ccanlint now says:
  Source files don't contain incompatible licenses (license_file_compat): FAIL
  /home/rusty/devel/cvs/ccan/ccan/md4/md4.c:Found boilerplate for license 'GPLv2+' which is incompatible with 'LGPLv2+'

This is actually GPL code!

Add LICENSE link, too.

This checks to make sure you're not accidentally relicensing code;
eg. it's OK (though a bit impolite) to turn a BSD-licensed file into a
GPL module, but not the other way around.

After discussion with various developers (particularly the Samba
team), there's a consensus that a reference to the license in each
source file is useful.  Since CCAN modules are designed to be cut and
paste, this helps avoid any confusion should the LICENSE file go
missing.

We also detect standard boilerplates, in which case a one-line summary
isn't necessary.

We really want everyone to be using these; establishing conventions
helps all code, so make it the most liberal license possible.  It's
all my code, so I can do this unilaterally.

Trivial code, all mine.

Trivial code, all mine.

We really want everyone to be using these; establishing conventions
helps all code, so make it the most liberal license possible.  It's
all my code, so I can do this unilaterally.

We really want everyone to be using these; establishing conventions
helps all code, so make it the most liberal license possible.  It's
all my code, so I can do this unilaterally.

Now we've made GPL wording uniform, use it everywhere.  There's no
point allowing variants which might be unclear.

We still have some non-conformant licenses in the tree (eg. just "BSD"),
so we only warn on unknown license strings for now.

GPL versions 2 and 3 both specifically mention "any later version" as
the phrase which allows the user to choose to upgrade the license.
Make sure we use that phrase, and make the format consistent across
modules.

This improves on the current ad-hoc methods, and also fixes a bug where
we mapped "GPLv2" to the GPLv3 symlink.

Turns out it's not standard (thanks Samba build farm!)
And the previous test had a hole in it anyway.  This one is more conservative.

I'm not sure that a "pthread-safe" tap library is very useful; how many
people have multiple threads calling ok()?

Kirill Shutemov noted that it gives a warning with -Wundef; indeed, we
should ask in this case whether they want pthread support, not whether the
system has pthread support to offer.

This file contains my private ramblings about the JSON module,
and was not meant to be included in the public release.