There are a large number of BSD variants out there, be explicit.

The upcoming failtest module can only tell that a child failed when it
exits with a non-zero error.  So we need this, although it means for ccanlint
it still needs to look at output to distinguish a memory leak from a real
error.

If an example #includes <ccan/foo/...> we assume it needs module foo,
but we would fail instead of building it if it isn't built.

As we start doing more building of dependencies, this saves us effort.

I chose not to do the "macro creates set of routines" approach, as
we can be almost as safe with a struct containing a pointer to the member
type.

I find hiding the declaration in LIST_HEAD() a bit weird.

In particular, we test the corruption cases.

Deletion from a specific list.

When CCAN_LIST_DEBUG was defined, we were previously calling
list_check() in list_del instead of list_check_node(), which caused a
warning.

We also should stick within the "list_" prefix namespace, so rename
"debug_list" to "list_debug".

We lose the histograms, but this prepares it for upstream merge.

One free record is not "uncoalesced".

Remove code duplication, and allow unit tests (which #include both).

Test compiled with warnings:
/home/rusty/devel/cvs/ccan/ccan/typesafe_cb/test/compile_ok-typesafe_cb-NULL.c:/home/rusty/devel/cvs/ccan/ccan/typesafe_cb/test/compile_ok-typesafe_cb-NULL.c: In function ‘main’:
/home/rusty/devel/cvs/ccan/ccan/typesafe_cb/test/compile_ok-typesafe_cb-NULL.c:18:2: warning: taking address of expression of type ‘void’
/home/rusty/devel/cvs/ccan/ccan/typesafe_cb/test/compile_ok-typesafe_cb-NULL.c:18:2: warning: taking address of expression of type ‘void’
/home/rusty/devel/cvs/ccan/ccan/typesafe_cb/test/compile_ok-typesafe_cb-NULL.c:18:2: warning: taking address of expression of type ‘void’
/home/rusty/devel/cvs/ccan/ccan/typesafe_cb/test/compile_ok-typesafe_cb-NULL.c:18:2: warning: taking address of expression of type ‘void’
/home/rusty/devel/cvs/ccan/ccan/typesafe_cb/test/compile_ok-typesafe_cb-NULL.c:18:2: warning: taking address of expression of type ‘void’
/home/rusty/devel/cvs/ccan/ccan/typesafe_cb/test/compile_ok-typesafe_cb-NULL.c:18:2: warning: taking address of expression of type ‘void’
/home/rusty/devel/cvs/ccan/ccan/typesafe_cb/test/compile_ok-typesafe_cb-NULL.c:18:2: warning: taking address of expression of type ‘void’
/home/rusty/devel/cvs/ccan/ccan/typesafe_cb/test/compile_ok-typesafe_cb-NULL.c:19:2: warning: taking address of expression of type ‘void’

If they specify valgrind options in their _info, we should use them when
running with --db-attach=yes, too.

This is complicated by valgrind's limited options, and our desire not to run
valgrind twice (it's already the slowest part of the tests).

Ideally I'd like a different error code for each kind of error.  I
could parse and pretty-print the XML output, but instead I just parse
the human-readable (which is fragile).

It requires that we build the objects first.

trbt_delete32() was broken and caused SEGV as soon as you tried to
delete an object from a tree.

Rework trbt_delete32() to instead just call talloc_free() instread of trying
to call delete_node() directly.
This makes the "from_destructor" argument to delete_node() redundant
so that parameter is removed too.
Signed-off-by: Ronnie Sahlberg <sahlberg@lenovo-laptop.(none)>

Unfortunately, gcc only warns if it sees an unknown attribute (in this case, gcc 4.1 vs "cold").

cc -g -Wall -Wstrict-prototypes -Wold-style-definition -Wmissing-prototypes -Wmissing-declarations -I. -MD -Werror   -c -o tools/ccanlint/tests/examples_run.o tools/ccanlint/tests/examples_run.c
cc1: warnings being treated as errors
tools/ccanlint/tests/examples_run.c: In function ‘scan_forv’:
tools/ccanlint/tests/examples_run.c:37: warning: passing argument 2 of ‘__builtin_va_copy’ discards qualifiers from pointer target type
tools/ccanlint/tests/examples_run.c:43: warning: passing argument 4 of ‘scan_forv’ from incompatible pointer type
tools/ccanlint/tests/examples_run.c:52: warning: passing argument 4 of ‘scan_forv’ from incompatible pointer type
tools/ccanlint/tests/examples_run.c:60: warning: passing argument 4 of ‘scan_forv’ from incompatible pointer type
tools/ccanlint/tests/examples_run.c: In function ‘scan_for’:
tools/ccanlint/tests/examples_run.c:78: warning: passing argument 4 of ‘scan_forv’ from incompatible pointer type
make: *** [tools/ccanlint/tests/examples_run.o] Error 1

It really doesn't like constifying a va_arg, so remove the const declaration.

Chris Cowan tracked down a SEGV in sub_alloc: idp->level can actually
be equal to 7 (MAX_LEVEL) there, as it can be in sub_remove.

(Imported from SAMBA commit 2db1987f5a3a)

Right-shifting signed integers in undefined; indeed it seems that on
AIX with their compiler, doing a 30-bit shift on (INT_MAX-200) gives
0, not 1 as we might expect (THIS WAS WRONG, REAL FIX LATER).

The obvious fix is to make id and oid unsigned: l (level count) is also
logically unsigned.

(Note: Samba doesn't generally get to ids > 1 billion, but ctdb does)
Reported-by: Chris Cowan <cc@us.ibm.com>
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>

(Imported from b53f8c187de8)

Author: Rusty Russell <rusty@rustorp.com.au>
Date:   Thu Jun 10 13:27:51 2010 -0700

Since idtree assigns sequentially, it rarely reaches high numbers.
But such numbers can be forced with idr_get_new_above(), and that
reveals two bugs:

1) Crash in sub_remove() caused by pa array being too short.
2) Shift by more than 32 in _idr_find(), which is undefined, causing
   the "outside the current tree" optimization to misfire and return NULL.

This causes a SEGV on my laptop.

We insert comments when we massage or combine examples; don't let these
throw off our analysis (as happened for idtree.h).

We might as well use the compiled .o rather than all the little .o files.

Out-by-one error had us using character prior to declaration, eg, in
"static int *foo" we use "*foo".  This seems to compile, but is weird.

Commit da72623a added a typo; ccanlint caught it, but doesn't consider
test compile failing to be fatal (it should!).

Specifically the linked free tables, and reflect on the status of each
point of the design document.