Joey Adams rightly points out that the current keys are a mess: ideally the
filenames, test keys and structure names in ccanlint should be the same.

First step is to make the test names all regular, of basic form <noun>_<verb>
(eg "tests_exist" rather than "has-tests").

This option prints the dependency graph of ccanlint's tests
in Graphviz .dot format.

Sample usage:

ccanlint --test-dep-graph | dot -Tpng > out.png && eog out.png

These tests:

	"depends-exist"      (compulsory_tests/check_depends_exist.c)
	"info-documentation" (tests/has_info_documentation.c)

used m->info_file without checking if it was NULL,
leading to a segfault when no _info file was present.

Some other tests also used m->info_file without depending on "info",
but are taken care of indirectly by this patch.

&*ptr is used in some other macros, but at a glance, they look like
cases where the pointer shouldn't be NULL .  Didn't change those,
and if we get more warnings, we'll cross that bridge when we get to it.
For now, I suppose they are just free NULL checks.

The parenthesized thing is confusing and ccanlint dislikes it.

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.