In a number of places the altstack module uses a literal '0' for pointer
values.  That's correct C, but doesn't make it obvious on a quick read
whether values are integers or pointers.  This patch changes those cases
to use the NULL define instead.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>

Functions invoked with altstack take a void * parameter.  However, the
test program wants to pass an integer, and so uses the trick of casting
the integer values to (void *) and back again.

The ptrint() module handles exactly this case in a more portable and
(somewhat) typesafe way, so use that instead.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>

altstack relies on catching a SIGSEGV caused when overrunning the stack.
This means that the SEGV handler itself can't use the already overflowed
stack, and so we use sigaltstack() to assign the signal handler a different
stack.  On completion, altstack() clears the alternate signal stack.

However, it's possible that the calling program could be using
sigaltstack() for its own reasons, so it's more correct to restore the
sigaltstack() state to that from the beginning of the altstack() call.
This patch implements this behaviour.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>

altstack uses a number of __thread variables to track internal state.  This
allows altstack to be thread-safe, although it's still not re-entrant.
This patch gathers all these variables into a single per-thread state
structure.  This makes it easy to see at a glance what the whole of the
required state is, and thereby easier to reason about correctness of
changes to the implementation.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>

Common case is mapping ints to structures.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>

Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>

Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>

Useful for unwinding actions taken while iterating over a htable.
Signed-off-by: Cody P Schafer <dev@codyps.com>

An odd omission from the tlist module is basic tlist_next() and
tlist_prev() macros matching list_next() and list_prev() in the basic
list module.  This adds them.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>

Sometimes it's not convenient to initialize an agar graph at runtime with
agar_init_graph().  This adds an AGAR_INIT_GRAPH() macro to do the same
thing as a static initializer.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>

These were left over from a previous approach which didn't pan out.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>

Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>

Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>

Signed-off-by: Cody P Schafer <dev@codyps.com>

I did not see any failures of other modules with this change, but I'm
not completely certain there are no cases that it breaks.
Signed-off-by: Cody P Schafer <dev@codyps.com>

When other macros are emitting LIST_INIT expansions, `name` can get a
bit complicated.
Signed-off-by: Cody P Schafer <dev@codyps.com>

Without this, one had to either use a function or a macro with casts to
get the expected behavior.
Signed-off-by: Cody P Schafer <dev@codyps.com>

Signed-off-by: Cody P Schafer <dev@codyps.com>

Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>

All modules have a _info file (a C file, despite the lack of extension)
giving metadata for the module.  The Makefiles have a rule to build these..
but it's broken (missing an include directive).

This patch fixes the rule, and builds the info binaries for all modules by
default.  This is a useful check and also useful for manually inspecting
a module's metadata.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>

Currently, build of ccan is controlled by two Make variables: MODS_WITH_SRC
and MODS_NO_SRC which list modules containing .c files, and modules with
only .h files respectively.

When adding new modules this is fiddly to get right, and there are a number
of modules already listed in the wrong variable.  There's also some
redundant logic in the DIRS variable to again filter out modules without
source.

This simplifies things by having a single manually updated MODS variable
listing every module, and determining MODS_WITH_SOURCE programmatically.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>

Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>

Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>

We used to crash, as reported by Stephen M. Cameron

Closes: #39
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>

Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>

Signed-off-by: Stephen M. Cameron <stephenmcameron@gmail.com>

Currently we pull auto-generated dependencies into the Makefile with
include ccan/*/*.d.  That will omit any .d files from nested modules,
meaning things might not be correctly rebuilt there.

Correct this by using the list of modules instead of a 1-level wildcard.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>

We currently generated .d dependency files with the -MD option to cc.  That
includes system header files in the dependencies, which isn't often useful
and makes the .d more complicated than necessary.

This changes to -MMD which excludes system headers.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>

Most of the ccan Makefiles use $(RM) to remove files.  However, 'rm' is
traditionally considered one of the few shell tools which can be used in
Makefiles without indirecting via a variable.

rm is also typically invoked with -f in Makefiles, so that it doesn't cause
errors if the files don't exist (because they haven't been built).  A
number of instances in ccan were missing this.

This corrects these warts.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>

At present, "make clean" will not remove the module-Makefile files for
non-top-level modules.  It also won't remove the generated config.h.
Correct those errors.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>

Seems to want more stack.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>

Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>

Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>

Turns out that patterns with / cause % to match /.  OK...
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>

Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>

Useful if you have more than one object with same key.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>

If we are to use should_grp_score_cos(x,y) as a filter the the following
relationship must hold (from least to most expensive):

        should_grp_score_len(x,y)
                >= should_grp_score_cos(x,y)
                >= grp_score(x)

should_grp_score_cos(x,y) wasn't holding up its part of the bargain, so
real data was used to generate a fudge curve to bring
should_grp_score_cos(x,y) results into the same space. Really this is a
terrible hack and the problem needs more thought. Evaluation of
should_grp_score_cos(x,y)'s performance benefit (given the relaxation of
the filter under the fudge curve) is sorely needed.

Distance metrics allow us to compare similarity results, however
applying the change leads to test suite breakage as we no longer satisfy
the requirement that each filter's score is at most as large as that of
the previous filter^. As such, also stop ccanlint from executing the
tests that are known to fail until we work around the problem.

^ This is a problem that has existed since the introduction of the
cosine similarity filter, it just wasn't detected by the test suite.

Ensure comparing filter results is sensible by using a consistent
calculation. Note that the cosine similarity measurement doesn't yet
conform and this can give spurious results that are not detected by the
test suite.

Likely this was optimised away, but the code now represents the intent.